[Sugar-devel] Regarding Social Help project

Prasoon Shukla prasoon92.iitr at gmail.com
Thu Mar 13 02:14:55 EDT 2014


I took a look at two of the webservices - Facebook and PutLocker.

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:
https://github.com/walterbender/facebook/blob/master/extensions/webservice/facebook/account.py#L53

However, in the PutLocker implementation, sugar is *actually storing
plain-text passwords! *Look here:
https://github.com/ignaciouy/sugar-putlocker/blob/master/extensions/webservice/sugarupload/account.py#L43
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.

This leaves us again with *any one* of these three options:

   1. Modify the browse activity as I mentioned in the last post.
   2. Store the hashes of the password and use one of the authentication
   hooks to log the user in as mentioned in the last post.
   3. 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.

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.

Thanks


On Thu, Mar 13, 2014 at 12:13 AM, Gonzalo Odiard <godiard at sugarlabs.org>wrote:

> Has you read about webservices support in Sugar?
>
> http://wiki.sugarlabs.org/go/WebServices
> http://wiki.sugarlabs.org/go/Features/Web_services
>
> Gonzalo
>
>
> On Wed, Mar 12, 2014 at 3:26 PM, Prasoon Shukla <prasoon92.iitr at gmail.com>wrote:
>
>> Hi Frederick, Sam.
>>
>> 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.
>>
>> 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:
>>
>> 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.
>>
>> 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.
>>
>> 3. The user can then close the browser. When the user opens the browser
>> again:
>>
>>    - we'll check if the session cookie exists.
>>    - if it does, then we do not need to write this cookie to the browser.
>>    - 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.
>>
>> This will log the user back in seamlessly without the need to fill in
>> authentication information.
>>
>> 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.
>>
>> 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 PBKDF2 hash<https://meta.discourse.org/t/why-does-discourse-use-pbkdf2/2934>.
>> Btw, they're using OmniAuth <https://github.com/intridea/omniauth> 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
>> ...).
>>
>> @Sam, @Frederick: Please let me know of a decision on this.
>>
>> Also, @Frederick, let me know if we need anything specific to
>> sugar-network other than what I mentioned earlier.
>>
>> Thanks
>> Prasoon
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>
>
> --
> Gonzalo Odiard
>
> SugarLabs - Learning Software for children
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140313/6e6938b8/attachment-0001.html>


More information about the Sugar-devel mailing list