If it can be made for the next release I would say let's keep it simple for
now, 3 roles :
-admin : can do all the CRUD operations + creating/deleting users
-developer: can do all the CRUD operations
-simple: can just do read operations
The default user (admin/123) should have the "admin" role.
Users created by the admin can have the role developer or simple
Users created by the admin will have the default 123 password to be changed
the first time they log in.
But !
The big questions remains around design, how to design that ?
Seb
On Tue, Nov 5, 2013 at 4:09 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
What's the plan moving forward here ?
-Matthias
On Thu, Oct 17, 2013 at 4:17 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
> Well, yes now that you said that :) Security based on Grouping.
>
>
> On Thu, Oct 17, 2013 at 4:15 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>
>> you mean grouping ?
>>
>>
>> On Thu, Oct 17, 2013 at 4:13 PM, Sebastien Blanc
<scm.blanc(a)gmail.com>wrote:
>>
>>>
>>>
>>>
>>> On Thu, Oct 17, 2013 at 3:44 PM, Matthias Wessendorf <matzew(a)apache.org
>>> > wrote:
>>>
>>>> any corp. org. may want some with just read-only access;
>>>> The project lead is allowed to update the keys etc, but all the
>>>> /normal/ developers can just see the IDs/secrets (so that they can use
it
>>>> in their server apps).
>>>>
>>>
>>> This is also an interesting point, at some point don't we want the
>>> "read" rights limited to a single/set of pushapps or even a level
deeper
>>> based on variants ?
>>> Maybe in a big company, Bob the slacker intern has read access for his
>>> supracool push app but also has access to the Public Relation Push App
>>> keys ...
>>>
>>>
>>>
>>>> I guess that's not really (at least for me) closely related to a
'test
>>>> via admin ui' feature
>>>>
>>>> -M
>>>>
>>>>
>>>> On Thu, Oct 17, 2013 at 3:39 PM, Corinne Krych
<corinnekrych(a)gmail.com
>>>> > wrote:
>>>>
>>>>> Not sure about the role: user.
>>>>>
>>>>> What will be the use case for this one?
>>>>> One use case, I see is if the 'user' is a tester. If we had
the
>>>>> feature to send push notification test via admin UI (as we discussed
in [1]
>>>>> and [2]).
>>>>>
>>>>> ++
>>>>> Corinne
>>>>> [1]
>>>>>
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Push-Server-Admin-...
>>>>> [2]
https://issues.jboss.org/browse/AGPUSH-38
>>>>>
>>>>> On Oct 17, 2013, at 3:09 PM, Matthias Wessendorf
<matzew(a)apache.org>
>>>>> wrote:
>>>>>
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Thu, Oct 17, 2013 at 2:54 PM, Sebastien Blanc <
>>>>> scm.blanc(a)gmail.com> wrote:
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Thu, Oct 17, 2013 at 2:35 PM, Lucas Holmquist <
>>>>> lholmqui(a)redhat.com> wrote:
>>>>> >
>>>>> > On Oct 15, 2013, at 11:14 AM, Sebastien Blanc
<scm.blanc(a)gmail.com>
>>>>> wrote:
>>>>> >
>>>>> >> So for the next Unified Push Release (0.9) it would be nice
if we
>>>>> could have some decent User Management, so I'm bumping this
thread again.
>>>>> >> Some existing pointer :
>>>>> >>
>>>>> >> - this thread :)
>>>>> >> -
https://issues.jboss.org/browse/AGPUSH-351
>>>>> >> -
https://gist.github.com/sebastienblanc/6547605
>>>>> >>
>>>>> >> First point to define is :
>>>>> >> - What roles do we want ? And what can these Roles do ?
>>>>> >
>>>>> > Admin - Can do all things including creating other users
>>>>> > Developer - can create apps and such. no access to the user
>>>>> management UI
>>>>> > User - read only - not sure if this one is needed
>>>>> > Yes, not sure also but why not ? Could be useful for a
monitoring
>>>>> app/RHQ plugin that just want to retrieve the list of active pushapps
...
>>>>> >
>>>>> >
>>>>> > +1 - I like these three different roles, including their rights
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >> - How can these Roles be created (granted ...)
>>>>> >> - Design
>>>>> >
>>>>> > I think we are still waiting on Hylke for this? not sure
>>>>> >
>>>>> >>
>>>>> >> Seb
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Tue, Sep 17, 2013 at 2:07 PM, Matthias Wessendorf <
>>>>> matzew(a)apache.org> wrote:
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Tue, Sep 17, 2013 at 2:04 PM, Apostolos Emmanouilidis
<
>>>>> aemmanou(a)redhat.com> wrote:
>>>>> >> Following the discussion on GitHub [1], here are some points
to be
>>>>> >> discussed about the user management flow:
>>>>> >>
>>>>> >> - Does it make sense to add a role select field (admin,
developer)
>>>>> on
>>>>> >> the enrollment page?
>>>>> >>
>>>>> >> hrm, and (perhaps later) a section where to define the roles
? I
>>>>> think it's a good point, but not sure we need all this
'now' :-)
>>>>> >>
>>>>> >> - Should we add an additional password field (password
>>>>> confirmation) on
>>>>> >> the enrollment page?
>>>>> >>
>>>>> >> yeah, would be nice
>>>>> >>
>>>>> >> - I think that the current logged in user shouldn't be
available
>>>>> for
>>>>> >> deletion
>>>>> >>
>>>>> >> yep, I agree
>>>>> >>
>>>>> >> [1]:
>>>>> >>
>>>>>
https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/pull/6
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Fri, 2013-09-13 at 10:15 +0200, Sebastien Blanc wrote:
>>>>> >> > A Jira has been created
>>>>>
https://issues.jboss.org/browse/AGPUSH-351
>>>>> >> > And draft structure has been created
>>>>> >> > here
https://gist.github.com/sebastienblanc/6547605
that can be
>>>>> used
>>>>> >> > as base for the Pull Request.
>>>>> >> >
>>>>> >> >
>>>>> >> > On Fri, Sep 13, 2013 at 5:53 AM, Douglas Campos
<qmx(a)qmx.me>
>>>>> wrote:
>>>>> >> > On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno
Oliveira
>>>>> >> > wrote:
>>>>> >> > > Would be nice to have a 8 hands document
on it
>>>>> >> >
>>>>> >> >
>>>>> >> > who's going to start the pull request on
it? it's
>>>>> SPECTIME!
>>>>> >> >
>>>>> >> > --
>>>>> >> > qmx
>>>>> >> >
_______________________________________________
>>>>> >> > aerogear-dev mailing list
>>>>> >> > aerogear-dev(a)lists.jboss.org
>>>>> >> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > _______________________________________________
>>>>> >> > aerogear-dev mailing list
>>>>> >> > aerogear-dev(a)lists.jboss.org
>>>>> >> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>> >>
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> aerogear-dev mailing list
>>>>> >> aerogear-dev(a)lists.jboss.org
>>>>> >>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Matthias Wessendorf
>>>>> >>
>>>>> >> blog:
http://matthiaswessendorf.wordpress.com/
>>>>> >> sessions:
http://www.slideshare.net/mwessendorf
>>>>> >> twitter:
http://twitter.com/mwessendorf
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> aerogear-dev mailing list
>>>>> >> aerogear-dev(a)lists.jboss.org
>>>>> >>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> aerogear-dev mailing list
>>>>> >> aerogear-dev(a)lists.jboss.org
>>>>> >>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > aerogear-dev mailing list
>>>>> > aerogear-dev(a)lists.jboss.org
>>>>> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > aerogear-dev mailing list
>>>>> > aerogear-dev(a)lists.jboss.org
>>>>> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Matthias Wessendorf
>>>>> >
>>>>> > blog:
http://matthiaswessendorf.wordpress.com/
>>>>> > sessions:
http://www.slideshare.net/mwessendorf
>>>>> > twitter:
http://twitter.com/mwessendorf
>>>>> > _______________________________________________
>>>>> > aerogear-dev mailing list
>>>>> > aerogear-dev(a)lists.jboss.org
>>>>> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog:
http://matthiaswessendorf.wordpress.com/
>>>> sessions:
http://www.slideshare.net/mwessendorf
>>>> twitter:
http://twitter.com/mwessendorf
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog:
http://matthiaswessendorf.wordpress.com/
>> sessions:
http://www.slideshare.net/mwessendorf
>> twitter:
http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev