Thank you both for your replies. On 9/2/2011 6:55 AM, Phil Ames wrote: > On Thu, Sep 1, 2011 at 12:56 AM, Joachim Fritschi > <[email protected] <mailto:[email protected]>> wrote: > > Am 31.08.2011 23 <tel:31.08.2011%2023>:30, schrieb Lars Huttar: > > 1) When the first unauthenticated request comes in: > - give the user a cookie with a unique id (I think this would > have to be > separate from the CASTGC, but I'm not sure) > - store the content of their POST data somewhere, tied to that id. > > Sound like a bad idea because storing post data would be pretty > much an invite of an attack in my eyes. LimitRequestBody which is > the only Apache setting to limit the size of POSTs to my knowledge > is by default unlimited with the addition of the 300s default > Timeout? Your idea would allow would allow a pretty easy memory > exaustion attack (DoS) > > > Yes, this is primarily why this feature or a variant is not currently > implemented. There are some other possible workarounds, i.e. encode > the POST data in the URL and somehow signal back to mod_auth_cas to > rewrite the request as such, but I think this is bound to be more > complicated, and won't scale to large POST bodies.
That was my thought too. > > In my eyes you should simply adjust your client to the cas setup > and make it cas aware: > > 1. Do a non POST hit on the webserver (mod_auth_cas protected) and > check if your cookie/login is still valid. If not do the normal > login and your simple hit will arrive at the server. (doing a dir > list or something simple you can think of in terms of server load) > > 2. Now you are sure you have a valid login/ticket. Now you > transfer you POST data. If something goes wrong. GOTO 1 > > > I'd suggest this approach if possible. Unfortunately the client is COTS software. I've asked the company for such a modification -- i.e. start with a simple GET request so that the authorization can finish before sending important POST data -- but they have a huge number of customers, and I have little reason to expect this to happen in the near future. > Just a pragmatic solution i would think. Another crazy idea could > be to obtain a Proxy Ticket for your application. It's basically > made for working with automated backend work of servers > (webservices,imap etc.) > Can you give any more details on what this would mean? Thanks, Lars -- 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
