persisting across redirect..

the way the facebook authorization scheme works is as follows:

1. on the first go round, facebook sends a POST with some data in it
   that needs to be parsed to pull an authorization code out of it.
2. if the app isn't authorized, i need to redirect to an authorization
   dialog to so that the user can authorize my app.
3. once the user does that, my app receives an oauth code, and i am on
   my way.

i have everything working, except, i am not sure where to store the
authorization code..

in my main component's renderOn, it looks to see if the a instance
variable 'oauthToken' is set. if not, it renders some javascript that
is really just a redirect to the facebook authorization screen.

once the app is authorized, 'oauthToken' is set to the correct value.

then, the authorization dialog sends the request BACK to the root
url..

everything works correctly..BUT.. on the second time back, the
redirect from facebook, it looks like it starts a brand new session
(there is a new instance of the main component created).

i was hoping that this would all be one session, and that i could just
set an instance variable once, and not even touch the session, but i
don't think this is going to happen. plus, it looks like i will be
firing up a new session on return anyway, so what i have saved in
session will be lost.

anyone have any ideas on how to cleanly persist this variable after
facebook's redirect?

--
----
peace,
sergio
photographer, journalist, visionary

http://www.ThoseOptimizeGuys.com
http://www.CodingForHire.com
http://www.coffee-black.com
http://www.painlessfrugality.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Can you store the oAuth code in an inst var in the user?





On 10/01/2012 07:45 AM, sergio_101 wrote:
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Mon, Oct 1, 2012 at 11:27 AM, Paul DeBruicker <[hidden email]> wrote:
> Can you store the oAuth code in an inst var in the user?
>


you, my friend, are smart!

that's exactly what i'll do..

trying to keep from having any reliance on the session..

thanks!

--
----
peace,
sergio
photographer, journalist, visionary

http://www.ThoseOptimizeGuys.com
http://www.CodingForHire.com
http://www.coffee-black.com
http://www.painlessfrugality.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Can you store the oAuth code in an inst var in the user?

dangit.. okay.. how to persist the user across the two different calls?

--
----
peace,
sergio
photographer, journalist, visionary

http://www.ThoseOptimizeGuys.com
http://www.CodingForHire.com
http://www.coffee-black.com
http://www.painlessfrugality.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 10/01/2012 10:39 AM, sergio_101 wrote:
>> Can you store the oAuth code in an inst var in the user?
>
> dangit.. okay.. how to persist the user across the two different calls?
>

In my session initialization method I create a new instance of my user
model and store it in the session.  If the person interacting with my
app during that session authenticates I replace the session user with
their user info that I've stored for that person as described here:

http://forum.world.st/Best-practices-available-for-Seaside-Gemstone-tp2721023p2901998.html


If they sign up instead I store the new instance of the user model with
their info as described above.


If they never sign up or authenticate the new user instance just gets
garbage collected eventually.



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside