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 server is sticking it onto the end of the return >> URL. It seems as though something at a lower level is replacing the >> URL or doing some redirect I can't see. >> >> I have stuck debug statements into my method, and a request for the >> casticket parameter always comes up empty: >> >> final String casticket = request.getParameter("casticket"); >> log.info(LogManager.getHeader(context, "loginPageURL", "casticket is: >> " + casticket)); >> >> >> (From the log file:) >> ...loginPageURL:casticket is: null >> >> Any ideas as to why I lose that parameter in the request in the >> XMLUI? Again, this works in the JSPUI. >> > > > > > ---------------------------------------------------------------------- > --- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > DSpace-tech mailing list > DSpace-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech ~~~~~~~~~~~~~ Mark R. Diggory Home Page: http://purl.org/net/mdiggory/homepage Blog: http://purl.org/net/mdiggory/blog ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
