Hardcoded references to error.jsp in AuthnEngine

[Cantor, Scott]

On 3/16/15, 4:35 PM, "Christopher Bongaarts" <cab at umn.edu> wrote:

>Was tracking down where users were reporting the 2.4.x equivalent of the 
>griffon page ("Our Identity Provider") when accessing /idp/AuthnEngine 
>despite our having configured alternate error page locations in 
>web.xml.  Discovered that there are several hard-coded references to 
>forwardRequest("/error.jsp", httpRequest, httpResponse) in 
>AuthenticationEngine.java.  Since this path seems to keep the HTTP error 
>code at 200, the web.xml error pages are never triggered (they only 
>activate on 500 or 404 errors).

Yeah, I always replace error.jsp with a forward to my "stale" page, because I think the hardcoded cases are when the login context goes missing.

>A couple questions:
>- Should I bother filing a bug on this in Jira, since 2.x will be EOL 
>soon and the 3.x code is radically different?

Filing bugs is fine, they just probably won't get addressed.

>- Is there a preferred way to address this?  Explicitly setting a 500 
>response code?  Using a catch-all (or at least catch 200, or does that 
>even make sense) error-page in web.xml?  Changing the forwardRequest to 
>a sendError?

I don't know what it could do. But I think there's a point of confusion in that the web.xml overrides are definitely *not* where error handling happens. That's basically extra. There's an explicit (but not universally used) error handling interface in the code and that's what actually sends to error.jsp in most other cases. In my case I override it with Velocity, which I documented in the wiki. The problem is that the authn code doesn't work with it once control passes to the servlet, I believe, which is why it's hardcoded there.

-- Scott