Hello -- It's not so much CAS and the redirects in general that are at issue during a non-interactive request dialog. Rather it's the fact that CAS uses the general purpose 302 response code as the redirect response code, and uses the HttpServletResponse.sendRedirect(String) method to do it, which you can't easilly override or change the behavior of.
Clients that can automagically follow redirects, like Jersey for example, will gladly follow the 302, but if the original request method was one other than a GET or a HEAD, Jersey and other clients I've experiemented with will perform the 302 redirect as a GET. Consequently if the original request requiring authentication is a POST for example, when the authentication redirect conversation between the initiating system, CAS and the target application is complete the final redirect is not the original POST request method but rather a GET. Certainly I could take command of the redirect dialog and at each stage of the authentication examine the response code, determine if it was an authentication redirect, manufacture another POST request to the location, etc. I don't want to force all of my consuming clients to do this. They really squawked when I talked about it too. With Jersey, I did some experimentation with some common redirect response codes to find out how it behaved with it's auto-redirect behavior enabled when issuing a POST method that results in a redirect response. The I codes I tested were ‘301 Moved Permanently’, ‘302 Found’, ‘303 See Other’ and ‘307 Temporary Redirect’. Here’s what I found POST that yielded '301 Moved Permanently' – Jersey redirected to Location header URI with GET request POST that yielded ’302 Found’ – Jersey redirected to Location header URI with GET request (what I am up against with CAS and CAS-ified target application access) POST that yielded '303 See other' – Jersey redirected to Location header URI with GET request POST that yielded '307 Temporary Redirect' – Jersey redirected to Location header URI with POST request and payload in place (hurray!!!) Consequently I see the 307 redirect results as the desired behavior for CAS-ified target application, non-interactive interactions. The definition of the 307 seems to fit into the use case too. That's all well and good, however looking at the number of redirects that CAS and the java CAS client implement, it appears relatively complicated to get a 307 generated rather than the stock 302 that is created today. However, that appears what I will be embarking upon. In summary I just wanted to share with the community what it is I'm doing with the issue, and the direction I hope to take to solve it. I don't have a fully fleshed out solution yet, i.e. what needs to get changed where, but I'll be working on that shortly. If anyone wishes to comment on the issue or how they may have addressed it, I'd love to hear from you. Thanks for reading. Peace. -- View this message in context: http://jasig.275507.n4.nabble.com/X509-authentication-POST-request-to-resource-turns-the-request-into-a-GET-tp4656744p4656774.html Sent from the CAS Developers mailing list archive at Nabble.com. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
