[OpenID] Flash based authentication?
Michael Graves
mgraves at janrain.com
Fri Mar 20 18:27:48 UTC 2009
Pete,
We've done a lot of work with Flash (AS3) widget machinery and OpenID
authentication, and we expect to have a Flash component added to the RPX
service we run, facilitating the kinds of interactions you're talking about
here.
First, as you point out, any embedded Flash object is subject to the scope
of its container (an HTML page, or maybe a Flash/Flex container inside an
HTML page) -- when the top level browser location changes, you're done.
Since the browser handles redirects, persisting the Flash object is not an
option, and when you go from "submit" to "handle an authenticated sign in"
redirect, you're starting from scratch. Typically, that's OK, since that is
a move from anonymous/guest mode to a "signed in" mode where the
authenticated user's profile data has been summoned from the database and is
used to "personalize" the page, and possibly the flash content, via
flashvars.
Anyway, the idea I wanted to raise is using Flash's "Shared Object", their
private "cookie" system, built into the player. If I understand you, that
may be a useful way to "bridge" the sessions when filling out big forms. The
amount of storage is limited (but can be substantial, ~100k is not uncommon)
and is controlled by the user. But having wrestled with this problem a bit,
that works well -- when the user needs to "refresh" their session, you may
be able to just store all the work in progress for the form in a Flash
shared object and send the user on their way to be directed to an OP, and
redirected back with a freshly authenticated session. When the user returns,
the saved form data will still be available in the stored shared object,
enabling the form to be "reconstituted" to the state it was in previously,
partially filled out by the user.
If I'm off base as to the amount of data you need to save (big uploads,
etc., more than Flash shared objects will store for that user), then this
won't help. Just wanted to point that out, as that's been a very useful
feature in our work on Flash-enabled OpenID apps. Flash player 10 also has
local file system access now, which is another option, and wouldn't be
subject to the user-set storage limits of the shared object.
Best,
-Mike
> Yeah thanks for that.
>
> This is the one reference I have seen to someone using OpenID in a flash
>
> context (and even better for me, a flex component).
>
> However, the live example he has I can't seem to get to load properly in
>
> my browser, and the demo says this upon submission of my identity:
>
> "Ideally, this is the handler where you send "ivt.com.au/openid/peter"
>
> for discovery to your backend. You could then call
>
> OpenIDLoginWindow.closeLogin(), use the response from discovery along
>
> with ExternalInterface.call() to communicate this URL with javascript so
>
> that the browser window is redirected there."
>
> The key phrase being "so that the browser window is redirected there",
>
> which will:
>
> a) break my requirement for not destroying the flash session (need to
>
> keep the player instance open so that everything stays in memory).
>
> b) Quite possibly cause problems with pop-up blockers.
>
> cheers,
>
> Pete
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090320/1e5b85e9/attachment-0002.htm>
More information about the general
mailing list