Trying to port "External" login handler
Cantor, Scott
cantor.2 at osu.edu
Tue May 20 11:40:34 EDT 2014
My saga continues, but I think I have a workable strategy for this
functionality.
I tried to use some tricks I found to access the flow state, and data
stored in it, from outside the flow, using a servlet filter, but that
ended up requiring very ugly webflow-config changes and on top of that a
cast to an internal SWF class, so I gave up on that.
I believe I can create essentially a duplication of webflow's
session-based store of conversational state, by storing a structure
wrapping the profile context and other data under a session attribute
named with a conversation key, probably derived from the flow execution
key.
I can then pass the conversation key on a query parameter in a redirect to
the external login point, and I've built an API for the external login
servlet or JSP to pull the data prepared for it from the session and into
request attributes, and then a finishing method similar to the old
"returnToAuthenticationEngine" approach that takes request attributes set
by the login handler and stores them back in the session, and then
redirects back to the webflow at the flow execution URL of origin.
The hitch with all this is that it uses redirects instead of forwards,
which is a throw-back to what Chad originally did and moved away from, but
in this case I think it's safer than that was because there are no query
parameters used other than as lookup keys into server state.
We're already totally dependent on the servlet session for SWF's own
state, so this is just adding more of the same, and it's entirely optional
for the use of this login strategy.
It will not be compatible with the V2 ExternalAuth interface because there
are changes required to get into and out of the login module anyway, but
it will be very similar. It does require tracking a conversation key on
the URL across all the interactions that the user plugs in, because
otherwise you'll end up with the same bugs we have today in V2 when
multiplexing login requests from a client.
-- Scott
More information about the dev
mailing list