CAS in IdP v3
Marvin Addison
marvin.addison at gmail.com
Thu Feb 4 11:32:52 EST 2016
On Thu, Feb 4, 2016 at 10:21 AM Cantor, Scott <cantor.2 at osu.edu> wrote:
> This is a Jetty specific bug, I take it?
No. Jetty actually provides a flag to disable the servlet-specified
behavior.
The root problem is that many Spring components that compute redirects
(RedirectView, externalRedirect SpEL) call
HttpServletResponse#encodeRedirectUrl [1] unconditionally. Here's where
it's biting us in the CAS login flow:
<end-state id="RedirectToService"
view="externalRedirect:#{flowScope.redirectUrl}">
<on-entry>
<evaluate expression="PopulateAuditContext" />
<evaluate expression="WriteAuditLog" />
</on-entry>
</end-state>
I initially argued that they should try to infer whether it's a "remote"
system and suppress that behavior, but I warmed up to "it's hard to
determine" and now I think they need additional flags to allow the
programmer to decide what to do. If they added those controls, we could
leverage them in the CAS flow. I suppose we could hack the view components
to suppress that behavior, but I think our time is better spent on the Jira
issue I mentioned. Until then, toggling the Jetty flag I mentioned is a
reasonable fix.
> We should start charging container projects to *not* choose them as our
> baseline.
>
What I can say about Jetty is that they are reasonably receptive to
thoughtful feature requests. That's worth something IMO.
M <users-unsubscribe at shibboleth.net>
[1]
http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#encodeRedirectURL(java.lang.String
)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160204/cd106522/attachment.html>
More information about the users
mailing list