ProfileRequestContext accessibility outside flow actions

Marvin Addison marvin.addison at gmail.com
Thu Aug 13 15:47:23 EDT 2015


>
> Right, and by then it's very likely the client has round-tripped, clearing
> any request attributes set by the first action in the flow.
>

You're right -- that would be true in general. I wasn't thinking about a
flow that paused while rendering a view state. On re-reading your initial
response, I see you said as much but I didn't pick up on it. What I
suggested will work for my case since the entire flow runs in single
request/response transaction via X509Internal.


> >I believe our implementation sketch would work beautifully with the patch
> I suggested.
>
> I don't think so. Did you actually try this? I'd be very confused if it
> worked.
>

I have not and you're right that InitializeProfileRequestContext won't work
in general.

Now, if you put it into AbstractProfileAction, that's another story...
> I can't think of any particular harm in setting a request attribute, but
> it creates some possible issues with overlap in the scopes in webflow.
> Since it's the same object in conversation scope as would be in request
> scope, that should be ok, but obviously is subject to testing.
>

Agree it seems innocuous, and I would argue it's generally beneficial.
Surely the need to get at context tree data from outside the flow execution
context will arise again. Are you open to a Jira enhancement request?

Obviously, I made explicit allowances for tunneling the PRC through the
> External login flow rather than trying to do something more invasive.


That was the inspiration for my suggestion :)


> Another option might be to accomodate this specific need in the resolver
> layer by doing it in ResolveAttributes itself.
>

At first I thought you meant the flow state, but now I'm re-reading it as
the action component. Might make sense, yeah, but I wonder if it would be
as generally useful. It's an esoteric use case admittedly, and exposing the
PRC in the request seems like a good and easy fix that provides a lot of
rope for unusual cases like this.

M <dev-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150813/68f2fbb8/attachment.html>


More information about the dev mailing list