On Thu, Sep 1, 2011 at 12:56 AM, Joachim Fritschi <[email protected]>wrote:
> Am 31.08.2011 23:30, schrieb Lars Huttar: > > His recommendation was to handle this entirely on the client >> (mod_auth_cas), not on the CAS server. (The patch I referenced for the >> CAS server is apparently intended to solve a different problem.) >> > One minor note, I notice you referenced https://source.jasig.org - we've moved the project to GitHub: https://github.com/Jasig/mod_auth_cas I believe other clients / the CAS server will be moving in the near future. > >> My colleague's idea, paraphrased, is to modify mod_auth_cas to do the >> following: >> >> 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. > > 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. > > 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.) > > Regards, > > Joachim > > > > > -- > 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<http://www.ja-sig.org/wiki/display/JSG/cas-user> > -- 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
