<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 5, 2013 at 5:58 PM, Sebastien Blanc <span dir="ltr"><<a href="mailto:scm.blanc@gmail.com" target="_blank">scm.blanc@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Tue, Nov 5, 2013 at 5:46 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
<br>
Matthias Wessendorf wrote:<br>
> If it can be made for the next release I would say let's keep it<br>
> simple for now, 3 roles :<br>
><br>
</div><div>> -admin : can do all the CRUD operations + creating/deleting users<br>
> -developer: can do all the CRUD operations<br>
> -simple: can just do read operations<br>
</div>+1 and oversimplifying here I would remove "simple". If people only can<br>
read send to them a PDF :)<br></blockquote></div><div>Yeah that could probably come later, but I still see some usages (see previous messages in this thread) </div></div></div></div></blockquote><div><br></div><div>agree</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>><br>
> The default user (admin/123) should have the "admin" role.<br>
><br>
> Users created by the admin can have the role developer or simple<br>
</div>Probably if the server is still using the interceptor, it must support<br>
multiple roles. What should I do into the following situations?<br>
<br>
- Delete ALL the things Endpoint annotated with developer and simple:<br>
Logged in user has only the simple role and is not a developer. Should I<br>
allow them to delete?<br></blockquote><div><br></div></div><div>Well, I was thinking of annotating methods, so delete all the thing will be only for "developer" and "admin"</div></div></div></div></blockquote>
<div><br></div><div>yup, that would be a bug on the UP Server (the actual annotation with "dev" and "simple" for the DELETE endpoint).</div><div><br></div><div>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?)</div>
<div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>><br>
> Users created by the admin will have the default 123 password to be<br>
> changed the first time they log in.<br>
</div>I think it was already solved on unified push server, no?<br></blockquote></div><div>Sure ! Just wanted to state it again that it will be the same for users created "manually". </div></div></div></div></blockquote>
<div><br></div><div>yep - it is already there</div><div><br></div><div>-M</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<div>><br>
> But !<br>
><br>
> The big questions remains around design, how to design that ?<br>
</div>Push the code and we refactor/improve/change it.<br>
><br>
> Seb<br>
<span><font color="#888888"><br>
--<br>
abstractj<br>
<br>
<br>
</font></span><br></div><div class="im">_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></div></blockquote></div><br></div></div>
<br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br>
<br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div>