<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>I believe our implementation sketch would work beautifully with the patch I suggested.<br>
<br>
I don't think so. Did you actually try this? I'd be very confused if it worked.<br></blockquote><div><br></div><div>I have not and you're right that <span style="font-size:13.1999998092651px;line-height:19.7999992370605px">InitializeProfileRequestContex</span><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">t won't work in general.</span></div><div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px"><br></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now, if you put it into AbstractProfileAction, that's another story...<br>
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.<br></blockquote><div><br></div><div>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?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Obviously, I made explicit allowances for tunneling the PRC through the External login flow rather than trying to do something more invasive.</blockquote><div><br></div><div>That was the inspiration for my suggestion :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Another option might be to accomodate this specific need in the resolver layer by doing it in ResolveAttributes itself.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>M<a href="mailto:dev-unsubscribe@shibboleth.net" target="_blank"></a><br>
</div><div><br></div></div></div>