[Seaside] Re: Fwd: OAuth/Twitter demo in Squeak

[Andreas Raab]

On 8/13/2010 8:21 AM, Miguel Enrique Cobá Martínez wrote:
> El jue, 12-08-2010 a las 21:01 -0700, Andreas Raab escribió:
>> [Oops, accidentally sent to seaside-*dev*; apologies for the noise]
>>
>> -------- Original Message --------
>>
>> Hi -
>>
>> I was playing with OAuth authentication and in the process decided to
>> test it against Twitter and since it's kind of fun, I thought I'd share
>> it with the rest of the world. You can run the (very simple) demo here:
>>
>> 	http://ardemo.seasidehosting.st/seaside/twitter
>>
>> All it does is after you log in via Twitter it shows you the account
>> info that Twitter shares with the app and allows you to tweet a little.
>>
>> The OAuth part itself is now integrated in WebClient's suite of auth
>> methods and the little Twitter demo is available in
>> http://www.squeaksource.com/ar.html and can be installed via
>>
>> 	(Installer ss project: 'ar')
>> 		install: 'Twitter-Squeak'.
>
>
> Cool, thanks for the work, this would permit to connect to facebook to
> (Facebook Connect).
> This opens a lot of opportunities for seaside apps. :)

Facebook is *much* easier in comparison since it doesn't use OAuth's 
obscure signature scheme and instead uses SSL. See 
http://developers.facebook.com/docs/authentication/

	"OAuth 2.0 is a simpler version of OAuth that leverages SSL for API 
communication instead of relying on complex URL signature schemes and 
token exchanges. At a high level, using OAuth 2.0 entails getting an 
access token  for a Facebook user via a redirect to Facebook. After you 
obtain the access token for a user, you can perform authorized requests 
on behalf of that use by including the access token in your Graph API 
requests..."

Cheers,
   - Andreas

>
>
>>
>> Since I found OAuth to be a pretty major PITA I hope that this example
>> will prove helpful for people who have to deal with this stuff.
>>
>> Lastly, a Seaside question that came up in the above: Part of the OAuth
>> process requires passing a specific callback url to the remote site
>> (which is the url the user gets redirected to after authentication was
>> successful). Since I couldn't figure out how to obtain the url
>> otherwise, I've been stashing it away in a rendering method (since
>> there's access to the rendering context's callback store) like here:
>>
>> renderLoginPageOn: html
>>
>> 	"Set up the callback url for Twitter to return to"
>> 	callback := WAActionCallback on: [self twitterCallback].
>> 	url := html actionUrl copy addField: (html callbacks store: callback).
>>
>> 	"We need the host and the scheme here; the scheme is guesswork"
>> 	urlString := 'http://', host, '/', url asString.
>> 	oauthParams at: 'oauth_callback' put: urlString encodeForHTTP.
>>
>> and then later the callback is passed to Twitter and the user sent back
>> to the app. This works, but I'm wondering if that's the right thing to
>> do, and if not, how one would set up and register such a callback url
>> outside of rendering.
>
> just use urlForAction method:
>
>
> html hiddenInput name: 'cancel_return'; value: (html urlForAction:
> [ self subscribeCanceled ]) ].
>
>
>
> Cheers
>
>>
>> Cheers,
>>     - Andreas
>>
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>