[dev] vhosts separation, user admin rights, userid based vhosts

Serge Chernyavsky serg.remote at gmail.com
Wed Nov 25 09:36:43 UTC 2009


Jan,

Jan Schneider wrote:
> Zitat von Serge Chernyavsky <serg.remote at gmail.com>:
> 
>> - Is there a standard way to delegate user management for non-admin 
>> user(s)? If not - what would be right place to code it in?
> 
> You would have to add admin sub-permissions to lib/api.php, e.g. 
> admin:users, then check for it in admin/user.php.
Did it by copying admin/user.php to separate folder and assigning rights 
to individual users to use it.

> 
>> - I use vhosts and external database for users. Admins are different 
>> per vhost basis. Of course environment should be separated. Would it 
>> be entirely wrong to use single database for everything and, say, auto 
>> assign unique group for users of each vhost and code in separation for 
>> shares, groups, users?
> 
> Yes, because it would keep you from using groups inside a domain. 
> Instead we should separate users by their domain names, when enabling 
> the vhost configuration flag in Horde. Or add another flag for that 
> purpose.
Went with database per domain for implementation and management simplicity

>> - I'm trying to implement vhosts based on domains taken from userid 
>> (all userids are in user at domain form). Tried to add  
>> $_SESSION['__auth']['userId'] handling in Horde::loadConfiguration and 
>> it works for logging in process but not for the later stuff. Could you 
>> advise how would it be better to implement it?
> 
> Not at all through the user name. Instead, have them logging in through 
> their own domain and use the vinfo or user name hook to automatically 
> add the domain to the user name. Then you can use the built-in vhost 
> setting to load different configurations per domain.
Do you mean that users at different domains should use different URLs 
according to their domains? Unfortunately it's not feasible for me 
because I want to use SSL and domains are entirely different (so 
wildcard certificate won't work either). And forwarding users to 
https://domain:port is not that good too because some browsers don't 
remember passwords and it URLs don't look nice.

So I finally did it in Horde::loadConfiguration and Registry constructor 
(it needed to re-read configuration after session_start).
Maybe using custom session handler would be better (a bit less patching) 
but I noticed there are several places where session starts and I need 
it only where importConfig() is issued. Another reason is that I'd like 
to keep it independent from session handler so it could work with any 
standard one without additional coding.

Any critics would be appreciated.

Serge


More information about the dev mailing list