more work on idp-distribution

[Cantor, Scott]

On 8/23/13 2:15 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>
>I don't fully understand how views work yet, but I've been wondering if
>the "display login form" action is supposed to be a view or not. I think
>it's not, in the current form, because it's just directly rendering a
>Velocity page manually. And I'm not sure I think that's wrong. I think we
>should be able to support actual view-states in the flows, but I'm not
>sure I think we should require that much machinery to grok just to get a
>simple page displayed.
>
>Obviously the consent stuff might be a different story.
>
>Anyway, this will start to get tested now that I'm working on the flow in
>the testbed.

And as Marvin predicted, this completely fails. Without a view-state, you
can't actually render anything to the client in the middle of a flow. You
also don't have a URL assigned to POST back to because a flow execution
URL isn't allocated until a view-state is rendered.

So we have to do views, or we have to redirect out of the webflow engine
into a separate servlet, akin to what we do now with the
AuthenticationEngine in V2. As much as I don't want to do views, I know
that not using web flow isn't really the right option for us, so I'm
working on the view option now.

That, I think, is going to imply some work to construct a simple "model"
object to capture the state to pass into the template and the
username/password coming out of it. I don't think we can rely on just
reading the form parameters directly inside an Action, but I'll find out.

I'm also thinking that doing our own basic-auth inside webflow is going to
be challenging. You need a view-state to be able to render an HTTP
response at all, but we have no actual "page" to protect with  basic-auth,
so it's going to be rather awkward. The main use case for this is the ECP
case, and trying to avoid requiring configuring basic-auth in the
container and just having it in one place.

-- Scott