<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 22, 2014 at 2:16 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Morning, answers inline.<br>
<br>
--<br>
abstractj<br>
<div class="im"><br>
On January 22, 2014 at 8:26:25 AM, Sebastien Blanc (<a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>) wrote:<br>
><br>
> Hi,<br>
> Since the User Management PR has been submitted [1] there has<br>
> been of a lot<br>
> of useful and interesting feedback, thanks Matzew and Abstractj<br>
> for that.<br>
><br>
> Some valid concerns has been raised, in particular 2 of them that<br>
> I would<br>
> like to expose here and to discuss to see how we can deal witth them<br>
> for<br>
> the 0.10.0 release :<br>
><br>
> 1.<br>
> Currently the password register/reset link that is generated<br>
> is persisted.<br>
> This is a point of concern[2]. The fact is that with the current<br>
> flow, we<br>
> can not go against that:<br>
><br>
> - An admin create an user, a link is generated.<br>
> - The admin send this link to the new user.<br>
> - The user browse to link -> at this moment we need to be able to retrieve<br>
> the stored link to check for its validity.<br>
<br>
</div>I completely understand that you guys need to release it by the end of this month and I’m not against it. The goal was just to alert about the risks and maybe create new Jiras for it (only to people know that we are aware of it).<br>
</blockquote><div><br></div><div>Well, even if it takes a bit longer (e.g. early Feb.), I think that is fine to have a few more days/weeks to get the 'User Management' in. Was supposed to be the 'big' item for 0.10 :) Other than that there were a few fixes and UI polish things. So IMO waiting a bit is perfectly valid - my personal opinion.</div>
<div><br></div><div>I am glad we are following up on these items, and eventually we create JIRAs :-) Thanks for the heads-up, Bruno!</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 class="im"><br>
><br>
> Some points :<br>
> - The token/register link is presisted without any relation<br>
> with the newly<br>
> created user, so an hacker could not make a connection between<br>
> the 2.<br>
<br>
</div>Maybe is my misunderstanding about the big picture, but the token has no relation with the newly created user, why do we have something like this? <a href="https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussion-diff-8996740R29" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussion-diff-8996740R29</a><br>
<div class="im"><br>
> - The new created user, as long he has not registered through the<br>
> link,<br>
> can not log into the system as he has no password, as Bruno suggested<br>
> me to<br>
> do on the ML.<br>
><br>
> How shall we deal with that for 0.10.0 ? We can improve in 0.11.0 <br>
<br>
</div>If we are aware of the improvements to the next release, why not? </blockquote><div><br></div><div>that would be fine w/ me as well</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just make sure to remove any relation between users and tokens (at least for password reseting) and also make it clear to the “admin” that with "great power comes with great responsibility”.<br></blockquote><div><br>
</div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I would suggest to point them to Jiras at our docs, we can always improve. <br>
<div class="im"><br>
> and also<br>
> keeping in mind that keycloak could come into the party quite<br>
> soon.<br>
<br>
</div>We need to keep our eyes in Keycloak, but they are still under development, the best approach is to make clear our needs, ideas and send some code to the project, IMO.<br></blockquote><div><br></div><div>yep, I agree!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
><br>
> 2.<br>
> Currently, to generate the register link, we use a private key.<br>
> This key is<br>
> located in the project[3]. This should not be in the github project<br>
> as<br>
> pointed by Bruno [4] which make totally sense. I will remove the<br>
> private<br>
> key from the repo and add instructions to tell how and where to<br>
> put your<br>
> private key.<br>
><br>
> But I don't know how to deal for the UPS cartdridge, since we ship<br>
> a war,<br>
> the private key will be missing. Any ideas input on that is welcome. <br>
<br>
</div>I can help on it and change my priorities if necessary, just not sure about the timing for you guys (I can do it today and make it available tomorrow for testing). </blockquote><div><br></div><div>IMO not worth rushing for today/tomorrow, as said above; If you can help that would be extremely awesome, but let's not change all of your priorities because of this :-) </div>
<div><br></div><div><br></div><div>-Matthias</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Some ideas:<br>
<br>
- Automagically generate the property file with the secret key, into this way that would be per application.<br>
- If we don’t have too much time, provide a script with the steps to upload the keys on OpenShift (maybe the first step is less confuse)<br>
<div class="im"><br>
<br>
> For 0.10.0, we could just ship a war containing a private key and<br>
> add a<br>
> warning and maybe add instruction on how to clone the app locally,<br>
> change<br>
> the key and push again (which is not really user friendly when<br>
> you expect<br>
> to have a cartdridge that "just work”).<br>
<br>
</div>+1 in the worst case scenario<br>
<div class="im"><br>
><br>
> Notice that there is ticket to be able to manage your private key<br>
> from the<br>
> Admin console[5]<br>
<br>
</div>That would be nice<br>
<div class="im"><br>
><br>
> Again, in the future, keycloak could be used also to manage the<br>
> keys.<br>
><br>
> Besides that, the current PR, in terms of functionnalities works<br>
> : you can<br>
> create and manage users like specified in the specs.<br>
><br>
> So for the (very soon) 0.10.0 release how shall we deal with these<br>
> concerns<br>
> ?<br>
<br>
</div>Looking at UPS roadmap (<a href="https://issues.jboss.org/browse/AGPUSH" target="_blank">https://issues.jboss.org/browse/AGPUSH</a>) the date for 0.10.0 is Wed, right? I think independent of our decision now, the timing is too tight to merge your PR and release it tomorrow, maybe we should release it on the next week? Or do not merge that PR?<br>
<div class="im"><br>
><br>
> Sebi<br>
><br>
><br>
><br>
> [1] <a href="https://github.com/aerogear/aerogear-unifiedpush-server/pull/118" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/pull/118</a><br>
> [2]<br>
> <a href="https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussion_r8996725" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussion_r8996725</a><br>
> [3]<br>
> <a href="https://github.com/aerogear/aerogear-unifiedpush-server/blob/register_link/src/main/resources/META-INF/config.properties" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/blob/register_link/src/main/resources/META-INF/config.properties</a><br>
> [4]<br>
> <a href="https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussion_r8996712" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussion_r8996712</a><br>
> [5] <a href="https://issues.jboss.org/browse/AGPUSH-518" target="_blank">https://issues.jboss.org/browse/AGPUSH-518</a><br>
</div>> _______________________________________________<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>
<br>
<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></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>