On Tue, Nov 5, 2013 at 5:58 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
On Tue, Nov 5, 2013 at 5:46 PM, Bruno Oliveira <bruno(a)abstractj.org>wrote:
>
>
> Matthias Wessendorf wrote:
> > 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
> +1 and oversimplifying here I would remove "simple". If people only can
> read send to them a PDF :)
>
Yeah that could probably come later, but I still see some usages (see
previous messages in this thread)
agree
>
> > The default user (admin/123) should have the "admin" role.
> >
> > Users created by the admin can have the role developer or simple
> Probably if the server is still using the interceptor, it must support
> multiple roles. What should I do into the following situations?
>
> - Delete ALL the things Endpoint annotated with developer and simple:
> Logged in user has only the simple role and is not a developer. Should I
> allow them to delete?
>
Well, I was thinking of annotating methods, so delete all the thing will
be only for "developer" and "admin"
yup, that would be a bug on the UP Server (the actual annotation with "dev"
and "simple" for the DELETE endpoint).
I think for the actual role management (how does it work?) it would be nice
that this (incorrect) DELETE invocation would have NO effect if the user is
a 'simple' user, but I guess that's perhaps a bit out of scope of the UPS -
more a security concerns (for PicketLink?)
>
> > Users created by the admin will have the default 123 password to be
> > changed the first time they log in.
> I think it was already solved on unified push server, no?
>
Sure ! Just wanted to state it again that it will be the same for users
created "manually".
yep - it is already there
-M
>
> > But !
> >
> > The big questions remains around design, how to design that ?
> Push the code and we refactor/improve/change it.
> >
> > Seb
>
> --
> abstractj
>
>
>
> _______________________________________________
> 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