Currently i think "Apps" are associated with a specific user, so if we introduce new users, then those new users won't be able to see any of the existing apps, even if they have the same roles.
this should probably change to be more role based, example:
Admin role:
All CRUD on Apps and CRUD user management
Developer:
CRUD on Apps
User:
just READ Apps
+1
On Sep 4, 2013, at 11:06 AM, Bruno Oliveira <bruno@abstractj.org> wrote:
>
>
> Sebastien Blanc wrote:
>> Hi,
>> Start point is this jira https://issues.jboss.org/browse/AGPUSH-282 for
>> allowing the creation of additional users/developers.
>> In the current situation we have just one role : "developer" , so the
>> first question is :
>>
>> - Should a user with the role "developer" be able to create another user ?
>
> It depends, I think is a matter of rules inside AGPUSH. Maybe we should
> have a role hierarchy definition? Would be nice.
>
>> - Should we introduce a "admin" role that can manage users (create,
>> reset password, delete) ?
>
> Makes sense.
>
>> - A mix of permissions ? (a developer can create other users but not
>> remove them nor reset (except its own) password )
>
> The hierarchy should be clear users/roles and levels, we can start a
> simple gist on it.
>>
>> From there the second question regarding password management :
>> In the current situation, our default user (called "admin" , yeah a bit
>> confusing :) ) has a temporary password that must be changed the first
>> time he logs in.
>>
>> - Do we want to keep this ?
>
> That is a old request from my side and violates CWE-798
> (http://cwe.mitre.org/data/definitions/798.html)
>>
>> - Shall we move to a script that creates a user(s) ?
>
> +1 for provide a script like "sample-db.sql" or whatever out of the box.
>>
>> - When we add a user through the admin UI, should we provide a password
>> or should it be generated and changed on first login ?
>
> In theory we should send the password reset instructions with the url to
> change it like:
>
> http://admin-ui.org/changeme/424242424242424 (Using the SecureRandom
> entropy from Java)
>
>>
>> In other words, I think we must concretely spec out the user management
>> for the UPS and we could use this thread to discuss that !
>
> +1 I'm all for it
>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> --
> abstractj
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev