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 queryof 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 server is sticking it onto the end of the return
URL. It seems as though something at a lower level is replacing the
URL
