Re: [Exist-development] Questions about users under 1.5dev

[Dmitriy S. <sha...@gm...>]

On Tue, Mar 1, 2011 at 3:30 AM, Joe Wicentowski <jo...@gm...> wrote:

> I just committed a fix (rev. 13878) to the Users admin panel, which
> was previously exhibiting errors.  However, there remain some issues
> with the xmldb module's user functions:
>
> 1. xmldb:delete-user() moves a user's record from
> /db/system/security/exist/accounts/ into
> /db/system/security/exist/accounts/removed -- and the user file is
> apparently unchanged.  Shouldn't the "expired" or "enabled" tags be
> updated to reflect that the user was "deleted"?  One side effect of
> the current behavior is that now, any scripts that rely on
> collection('/db/system/security/exist/accounts) to get a list of all
> current users need to check each record's parent-collection to make
> sure it is not in the "removed" folder.
>

I do plan to add policy for passwords,  'expired' will be used to flag
change password only possible action for account.
'enabled' is simples way to disallow to access db by this account. (to be
implemented)

to solve 'deleted' issue I can add attribute to highlight this.


> On a related note, what effect does "expired=true" or "enabled=false"
> have on the database?  What do these mean?
>
> 2. xmldb:create-user() and xmldb:change-user() are inconsistent about
> creating groups and home collections that don't already exist.
>
> The Users admin panel indicates that xmldb:change-user() will create
> groups, when editing a user's record: "Note: non-existing groups will
> be created automatically."  However, in my tests, neither function
> creates a group.  For example:
>
>  xmldb:login('/db', 'admin', 'password'),
>  xmldb:create-user('user1', 'pass1', 'group1', '/db/group1')
>
> => creates a user account as follows
>
>  <account xmlns="http://exist-db.org/Configuration" id="8">
>    <password>{MD5}pyLGPbjshiWvbPccuMLZOQ==</password>
>    <home>/db/group1</home>
>    <expired>false</expired>
>    <enabled>true</enabled>
>    <name>user1</name>
>  </account>
>
> Note that there's no <group>group1</group>.
>
> Note also that the previously non-existent "/db/group1" collection *is*
> created!
>
> 3. But then if I then change the user's home collection:
>
>  xmldb:login('/db', 'admin', 'password'),
>  xmldb:change-user('user1', (), 'group1', '/db/group2')
>
> ==> modifies the user account as follows:
>
>  <account xmlns="http://exist-db.org/Configuration" id="8">
>    <password>{MD5}pyLGPbjshiWvbPccuMLZOQ==</password>
>    <digestPassword>646b3170d7a15e64ff0c3fb96c93c14b</digestPassword>
>    <home>/db/group2</home>
>    <expired>false</expired>
>    <enabled>true</enabled>
>    <name>user1</name>
>  </account>
>
> Note that this time, the non-existent collection "/db/group2" is *not*
> created!  So xmldb:create-user() does create a non-existing
> collection, whereas xmldb:change-user() doesn't.  Is this a bug?
>

Yes, this is a bug ... (non-existent collection)

Question: Should '/db/group1' renamed to '/db/group2'? or create new?


>
> Note also that in addition to the original <password> we now
> mysteriously have a <digestPassword>; why are there 2 passwords, and
> why is digestPassword only created after the change-user() runs?
>

digestPassword is artifact ... it used previously and trying to run away
from it...


>
> Note also that "group1" is still not created or applied to the user.
> To create a group, I have to explicitly call xmldb:create-group().
> I'm guessing this is because xmldb:create-group() now requires a group
> manager.  If I'm correct, then we need to remove the text "Note:
> non-existing groups will be created automatically" from users.xqm.
>

Well, I prefer to remove this text...


>
> 3. Is there interest in improving the user management that can be done
> via the Users admin panel?  I know that the panel warns, "Note: this
> is work in progress. Don't use this page to manage users in a
> production environment. Use the Java client instead."   Is this
> warning here simply because the admin panel isn't "polished", or
> because the default eXist installation can't assume users are
> operating over an HTTPS connection?  I could certainly do some work on
> improving the Users (+Groups) panel.  But what would it take for us to
> be able to use such a panel in production -- HTTPS only?  Or are there
> other things that need to be changed from a production environment
> perspective?  Also, is the Java client any more "secure" from a
> sniffing/security perspective, or is it just more polished?
>

Personally, I  do believe that web panel must be primary tool. So, if you
can help to improve this, you are welcome! :-)

Authentication issues will be solved soon or later ...


> 4. There is now a "securitymanager" module.  The function
> documentation for this module
> (http://localhost:8080/exist/functions/sm) describes things like
> user's names (in addition to username) and account metadata.  I look
> forward to learning more about this module and the new security design
> as it relates to users and groups.
>

This module will have some more function soon ...

-- 
Dmitriy Shabanov

PS Joe, thanks for testing ...