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.)
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)
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
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
