[#5844] inconsistency when using _username_{from,to}backend hooks
Summary inconsistency when using _username_{from,to}backend hooks
Queue Horde Framework Packages
Queue Version HEAD
Type Bug
State Resolved
Priority 1. Low
Owners jan (at) horde (dot) org
Requester steinkel (at) ctinetworks (dot) com
Created 2007-10-30 (4829 days ago)
Updated 2007-11-23 (4805 days ago)
Assigned 2007-11-12 (4816 days ago)
Resolved 2007-11-23 (4805 days ago)
Patch No

2007-11-23 16:20:01 Jan Schneider Comment #5
Assigned to Jan Schneider
State ⇒ Resolved
Reply to this comment
The patch looks pretty straight forward, thanks.
2007-11-14 18:35:11 steinkel (at) ctinetworks (dot) com Comment #4
New Attachment: share-perms.patch Download
Reply to this comment
This is where I am as far as permissions-management in a 
backend-hook-using environment. I am testing these with mnemo with the 
assumption that once it works there it will work everywhere.  I am 
having other issues with mnemo duplicating notepads that may or may 
not be related to this.

I hope you will look at these and see more general fixes to the 
particular problems I am battling.
2007-11-13 15:50:19 steinkel (at) ctinetworks (dot) com Comment #3 Reply to this comment
I accept that my concept of the backend hooks might have been skewed.   
I can make FTP and other "backend" services use the internal username 
for authentication.  That will even add an extra level of "security 
through obscurity" without lessening password protection.

I have been looking at templates/shares/edit.inc and 
services/shares/edit.php.  I tweaked the former by adding 
Auth::removeHook() calls in appropriate places and it seems to be 
doing what it should.  I was having difficulties with getting edit.php 
to call Auth::addHook() in the correct places, then I was called away 
to something else.

I hope to get back to working on this for the time being, to the point 
of having patches for edit.inc at least by this afternoon
2007-11-12 00:06:13 Chuck Hagenbuch Comment #2
State ⇒ Feedback
Reply to this comment
So, to make sure I'm clear on what the fixes would be:

- When displaying usernames with shares, run them through 

- When saving usernames for shares, run them through username_hook_tobackend

That seems pretty straightforward and in the spirit of those hooks. 
The other stuff, though, is getting a little hairy. The username hooks 
have historically been for translating the username to _the_ backend 
username, across all backends, not just to the Horde backend. Many 
people would use them to translate a user-friendly username to a fully 
qualified username that is then used for all services, like LDAP.

So I think a different concept or hook might be necessary to represent 
a "Horde internal" vs. "All other external" username.
2007-10-30 17:31:03 steinkel (at) ctinetworks (dot) com Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ inconsistency when using _username_{from,to}backend hooks
Queue ⇒ Horde Framework Packages
Reply to this comment
I used uidNumber as an internal handle so usernames can be changed 
without loss of data stored in horde.  Now I find that horde is trying 
to use the handle for accessing non-horde services, such as FTP 
storage of ingo scripts and LDAP lookups for group memberships.  It 
also required me to enter the uidNumber for a user to share with a 
specific individual, rather than their username.

Saved Queries