Randall, It should work the same way. I'm unsure why you are loosing
the query detail from your return response. I think that we should
ask Scott Philips if he has any opinion on this subject.
Heres one possibility to explore:
The AuthenticationUtil.resumeRequest method may be returning an older
original request for the authenticator because it is only checking
the "path" and not the "query"of the URL.
I would pepper this method with some logging or trace it with a
debugger and see if you are falling into it.
On the note of debugging it a lot easier to trace through the
executing code using the Eclipse debugger attached to your tomcat
instance, than it it to alter the code with debugging lines and
recompiling, I would recommend utilizing that tool ti figure out
where the failure is happening.
http://andrej.racchvs.com/archives/2003/10/23/using-eclipse-to-debug-
your-tomcat-web-application/
http://www.eclipsezone.com/eclipse/forums/t53459.html
> /**
> * Check to see if this request should be resumed.
> *
> * @param realHttpRequest The current real request
> * @return Either the current real request or a stored request
> that was previously interrupted.
> */
> public static HttpServletRequest resumeRequest
> (HttpServletRequest realHttpRequest)
> {
> // First check to see if there is a resumed request.
> HttpSession session = realHttpRequest.getSession();
> //session.setMaxInactiveInterval(60);
> Object object = session.getAttribute(REQUEST_RESUME);
>
> // Next check to make sure it's the right type of object,
> // there should be no condition where it is not - but always
> // safe to check.
> if (object instanceof RequestInfo)
> {
> RequestInfo interruptedRequest = (RequestInfo) object;
>
> // Next, check to make sure this real request if for the
> same url
> // path, if so then resume the previous request.
> String interruptedServletPath =
> interruptedRequest.getServletPath();
> String realServletPath = realHttpRequest.getServletPath();
>
> if (realServletPath != null &&
> realServletPath.equals(interruptedServletPath))
> {
> // Clear the resumed request and send the request back
> to
> be resumed.
> session.setAttribute(REQUEST_INTERRUPTED, null);
> session.setAttribute(REQUEST_RESUME, null);
>
> return interruptedRequest.wrapRequest(realHttpRequest);
> }
> }
> // Otherwise return the real request.
> return realHttpRequest;
> }
-Mark
On Sep 30, 2008, at 10:34 AM, Floyd, Randall Dean wrote:
> Let me try this again, but I'll back up and ask it in a much more
> general way. Does the XMLUI use the stackable authentication
> mechanism
> in the same way that the JSPUI does? I'm going through the code
> trying
> to follow the flow, and I'm starting to question whether the eperson
> aspect in Manakin is going to call the methods of my authentication
> class in the same way as the JSPUI. And again, just to be clear, this
> an implicit CAS authentication method that works in my DSpace 1.5.1
> environment using the JSPUI. It doesn't work in the XMLUI. Details
> are
> in the original message, but it would really just be helpful if I knew
> whether or not this is going to work at all in the XMLUI, and if not,
> where I can go for clues on how to write a different method.
>
> Quoting "Floyd, Randall Dean" <[EMAIL PROTECTED]>:
>
>> Hi all,
>>
>> I have a custom authentication method that works in DSpace 1.5.1
>> JSPUI but does not work in the XMLUI. Essentially this is a custom
>> method that sends a user to a CAS login page and back for further
>> validation of the CAS ticket. The root issue seems to be that I am
>> losing essential parameters in the HTTP request, and that is where my
>> casticket is supposed to be. That is, at my institution, the CAS
>> server tags the CAS ticket string onto the end of the URL that CAS is
>> going to send the browser back to. So, when this works in JSPUI, I go
>> to the CAS login server, and when it comes back to DSpace, it will
>> always look something like:
>>
>> .../dspace/mydspace?casticket=ST-205536...(some long string)
>>
>> That 'casticket' parameter is essential for everything that happens
>> next in my method in the stack. Without it, I can't check to see
>> where I am in the process, and I don't have a ticket ID to validate
>> against the CAS server.
>>
>> In the XMLUI, I am losing that casticket parameter. The browser goes
>> off to the CAS login server, and then comes back to DSpace/XMLUI and
>> goes down through the stack methods again. Problem is, on this
>> second time around, I don't have that casticket parameter in the URL,
>> even though the CAS se
