<div dir="ltr">I took a look at two of the webservices - Facebook and PutLocker.<div><br></div><div>Now, Facebook provides an access token that can be used to log the user in via third-party clients. As far as I can see, Discourse does not provide such access tokens. The Facebook access token being used is here: <a href="https://github.com/walterbender/facebook/blob/master/extensions/webservice/facebook/account.py#L53">https://github.com/walterbender/facebook/blob/master/extensions/webservice/facebook/account.py#L53</a></div>
<div><br></div><div>However, in the PutLocker implementation, sugar is <i>actually storing plain-text passwords! </i>Look here: <a href="https://github.com/ignaciouy/sugar-putlocker/blob/master/extensions/webservice/sugarupload/account.py#L43">https://github.com/ignaciouy/sugar-putlocker/blob/master/extensions/webservice/sugarupload/account.py#L43</a></div>
<div>This, IMHO, is a big mistake. Many users tend to keep the same password on different websites - and having the plain-text password stored in a file is nothing short of giving away your account to anyone who uses your laptop. I do not know why this is being used but I refuse to use this method.</div>
<div><br></div><div>This leaves us again with <u><b>any one</b></u> of these three options:</div><div><ol><li>Modify the browse activity as I mentioned in the last post.</li><li>Store the hashes of the password and use one of the authentication hooks to log the user in as mentioned in the last post.</li>
<li>Or, and I personally do not like this option, get the users to log in to discourse via Facebook. My primary reason for not liking this is that we'll be tying up authentication to a non-free (as in freedom) service. But, we can go through with this, if this appeals to the community.</li>
</ol><div>Personally, I like #1 and #2. But, the final decision on this is not mine to make since I'm a very new member of the sugar community. So, let us discuss this issue here and reach a decision soon so that I can finish writing my proposal.</div>
</div><div><br></div><div>Thanks</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 12:13 AM, Gonzalo Odiard <span dir="ltr"><<a href="mailto:godiard@sugarlabs.org" target="_blank">godiard@sugarlabs.org</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">Has you read about webservices support in Sugar?<div><br></div><div><a href="http://wiki.sugarlabs.org/go/WebServices" target="_blank">http://wiki.sugarlabs.org/go/WebServices</a><br>
</div><div><a href="http://wiki.sugarlabs.org/go/Features/Web_services" target="_blank">http://wiki.sugarlabs.org/go/Features/Web_services</a><br>
</div><div><br></div><div>Gonzalo</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Mar 12, 2014 at 3:26 PM, Prasoon Shukla <span dir="ltr"><<a href="mailto:prasoon92.iitr@gmail.com" target="_blank">prasoon92.iitr@gmail.com</a>></span> wrote:<br>

</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hi Frederick, Sam.<div><br></div><div>Well, the way I imagine this project is that a user can launch into a Discourse discussion in a Browse activity. This activity can then be shared as any other activity - this part will not require any other specific changes to be made (if I understand your request correctly). We can, however, add links to the discussions on Discourse on the sugar-network website in the relevant places.</div>




<div><br></div><div>Anyway, I tried to think of a few ways in which we can preserve a user session across discussions. Finally, I've decided on the following flow:</div><div><br></div><div>1. Get the user to register the first time - this process is very easy and we can pick email directly from sugar. Then, the part before the '@' can be the default username for Discourse (this the user can of course change). The user will need to enter the password though.</div>



<div><br></div><div>2. Discourse will create a session for the user and send the browser the session information(cookies). Now, and this is a crucial point, I'll need to modify the browse activity to add a method that can will return session information (the session cookie) to the calling process. I'll call this method via DBus to retrieve the this information. We'll then store this in a configuration file.</div>


<div><br></div><div>3. The user can then close the browser. When the user opens the browser again:</div><div><ul><li>we'll check if the session cookie exists.<br></li><li>if it does, then we do not need to write this cookie to the browser.</li>


<li>otherwise, we'll retrieve the session cookie from the config file and write it to the browser - this will need another method to be added to the browse activity.</li></ul><div>This will log the user back in seamlessly without the need to fill in authentication information.</div>


</div><div><br></div><div>Now, if we go through with this implementation strategy, then our only concern at this stage will be whether the getCookie and setCookie can be implemented in the browse activity. Of course, getting and setting cookies can be done via JS in any webkit browser. So, I think it shouldn't be difficult to do this.</div>


<div><br></div><div>Now the decision remains whether to proceed with this course or not (in which case we'll probably need to talk to discourse devs about how to log users in directly with a<a href="https://meta.discourse.org/t/why-does-discourse-use-pbkdf2/2934" target="_blank"> PBKDF2 hash</a>. Btw, they're using <a href="https://github.com/intridea/omniauth" target="_blank">OmniAuth</a> for authentication and they also provide quite a few authentication hooks to tweak authentication according to our needs, so it shouldn't be too hard ...).</div>


<div><br></div><div>@Sam, @Frederick: Please let me know of a decision on this.</div><div><br></div><div>Also, @Frederick, let me know if we need anything specific to sugar-network other than what I mentioned earlier.</div>


<div><br></div><div>Thanks</div><span><font color="#888888"><div>Prasoon</div></font></span></div>
<br></div></div><div class="">_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br></div></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Gonzalo Odiard<br><br><div>SugarLabs - Learning Software for children<br></div></div>
</font></span></div>
</blockquote></div><br></div>