Thanks for all the suggestion: I do appreciate them. We now see that the request are sometimes correct (e.g. only POST's) and sometimes there is a GET followed by a POST. So my FLEX college is now digging into FLEX to find out why. Thanks all for the help! Regards, Richard ________________________________
From: Adam Rybicki [mailto:[email protected]] Sent: Tue 2-6-2009 22:26 To: [email protected] Subject: Re: [cas-user] POST gets changed to GET Richard, I think that what Andrew was suggesting was that the "filter," whatever that is, should hang on to the POST data and "replay" it once CAS redirects back to the protected service. CAS is redirecting with a service ticket because it still has a valid SSO ticket. The session on your proxy server, however it is implemented, has probably expired. I am not aware of any CAS client with a capability to preserve POST data. So, what is the "filter" protecting your proxy server? Adam Spruit, Richard wrote: > Thanks, Andrew, for the suggestion. However, the POST-request doesn't get > past the first filter, so the proxy never 'sees' the body of the request. We > would prefer not to build our own filter(s). Or did I miss something? > > Regards, > > Richard > > > ________________________________ > > From: Andrew Tillinghast [mailto:[email protected]] > Sent: Mon 1-6-2009 14:30 > To: [email protected] > Subject: Re:[cas-user] POST gets changed to GET > > > > We had a similar problem with one of our home grown CAS apps, what you need > to do is store the post values in session variables before you send the user > back to CAS for validation. Then when they validate cycle the session > variables back into the request scope and process normally. > > -Andrew > > On Jun 1, 2009, at 7:53 AM, Spruit, Richard wrote: > > > Hello all, > > We have build our own proxy, which is casified. Some Flex applications > are using this proxy to get acces to some backend SOAP-services. This became > a bit of a large post, but we rather are puzzled by which direction we should > proceed. > > The Flex-applications are sending http POST-requests to the proxy. What > we see in the log of the proxy, after some time, is that it recieves GET > requests with a ticket attached to the url. Our understanding is that: > > - the CAS-filters of the proxy recieve the POST-request, but had a > session timeout, so any request is redirected to the CAS-server. > > - Somehow the CAS-server did not have a session-timeout, so the request > is redirected to the proxy, but now with a ticket attached. The request is by > the CAS-server changed into a http GET-request. > > - our proxy sends the request to the backend SOAP-service and recieves > an error since the request is now a http GET-request. > > > About this all we have a lot of questions, being the first if our > understanding is indeed correct. Is this the 'expected behaviour'? > > Next, we need to figure out what we can do about this. > 1. Is there a way for the Flex application to know there has been a > session-timeout? For example: should they recieve a HTTP 302 error or > something? If so, our Flex-application are automatically resending the > request, since we did not program anything to resend a request. Anyone out > there who can tell my college how to recognise such a response in Flex? > > 2. Is there a way to configure CAS so that is redirects an http POST > request as a POST-request instead of a GET-request? > > 3. Is there anything we are missing? Maybe a suggestion for a different > approach? Please keep in mind that our SOAP back-end services themselves are > *not* casified, only the proxy. > > Any help is much appreciated, regards, > > Richard > > > > > > > Please help Logica to respect the environment by not printing this email / Pour contribuer comme Logica au respect de l'environnement, merci de ne pas imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei die Umwelt zu schuetzen / Por favor ajude a Logica a respeitar o ambiente nao imprimindo este correio electronico. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -- 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-user
<<winmail.dat>>
