On Wed, 27 Jun 2012, Phil Ames wrote: > This has been changed in master: > > https://github.com/Jasig/mod_auth_cas/commit/e95e701ea1650e0e18a0e7fcb6d5f470ffb19602 > > Historically, all that was returned was: > yes\n > [username] > > or a very small XML document. With SAML attributes, obviously > additional space is useful. If someone's pushing out more than 16k of > attributes, then we can look at changing the value or strategy, but > adding complexity to allocate / resize doesn't seem really necessary > at this point. > > -Phil
OK, thanks for the info. Guess that seems reasonable. A larger value of CAS_MAX_RESPONSE_SIZE seems like it'll work for us, plus we didn't want to bother dealing with the changes necessary to do it dynamically (my C programming is a little rusty, plus we're not the official source for this). I don't know how people are using this, so don't have a good feel for how important it is to do it dynamically, rather than just setting a reasonable static value. Milt Epstein > On Wed, Jun 27, 2012 at 1:05 PM, Milt Epstein <[email protected]> wrote: > > That did it. ?We weren't getting any errors in the (apache) logs > > (perhaps because our log level wasn't set detailed enough), but I > > tried upping the value of CAS_MAX_RESPONSE_SIZE (it was 4096, I tried > > 16384 and 131072), and it worked -- the user was able to log in > > without problem. ?Thanks. > > > > So, looking at the code, CAS_MAX_RESPONSE_SIZE is used for a buffer > > used within a call to curl. ?It looks like that is for the entire > > response from the cas server. ?Why was it decided to use a static > > value for that, rather than handle it dynamically? ?Wouldn't that > > potentially cause problems of the sort we ran into? ?Any chance that > > could be changed? > > > > Thanks. > > > > Milt Epstein > > > > > > On Tue, 26 Jun 2012, David Hawes wrote: > > > >> On 2012-06-26 18:22, Milt Epstein wrote: > >> > Hi. ?We're having a problem that I was wondering if someone here might > >> > have some suggestions on how to deal with. ?One of the attributes > >> > we're passing (from LDAP) is a multi-valued attribute, and one of our > >> > users has many many values for this attibute in his entry. ?He was > >> > having trouble logging in to a test client we had set up using > >> > mod_auth_cas, and we had the idea that it might be related to the size > >> > of this attribute. ?So I removed it from the list of allowed > >> > attributes for one of our registered servers, and he was then able to > >> > log in to that server. ?(Prior to that, the failure varied somewhat by > >> > browser/platform -- in some cases, he just got a not authorized page, > >> > and in other cases, there was a loop/too many hops because it kept > >> > going back and forth between the server and the cas server.) > >> > > >> > Our first thought was that there was something in mod_auth_cas that > >> > was not handling this large attribute -- maybe a static size that was > >> > set too small -- but we have not debugged this completely yet. ?(As > >> > some data for comparison purposes, I was not having any trouble > >> > logging in, and I have 14 values for this attribute, with a total size > >> > of about 150 characters; the other user had 50 values totalling about > >> > 500 characters.) ?If so, we might be able to modify mod_auth_cas > >> > locally to handle this situation (and maybe generate a bug report that > >> > leads to this being fixed in the released code). ?Does anyone have any > >> > insight into what in particular might be leading to this problem? > >> > > >> > Of course, it's possible that this problem is not related to the size > >> > of the attribute -- for instance, maybe one of the values has a bad > >> > character in it. ?But further debugging should give us more info about > >> > this. > >> > > >> > This user can log in just fine to our Moodle server (which also uses > >> > cas), which is what leads us to believe that the problem is on the > >> > mod_auth_cas side, rather than the cas server side. ?(Of course, this > >> > could be wrong too). > >> > >> If you notice an oversized response error message in your logs, increase > >> the following value in mod_auth_cas.h and recompile: > >> > >> CAS_MAX_RESPONSE_SIZE > >> > >> -- > >> 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 > >> > > > > Milt Epstein > > Applications Developer > > Graduate School of Library and Information Science (GSLIS) > > University of Illinois at Urbana-Champaign (UIUC) > > [email protected] > > > > -- > > 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 > > -- > 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 > > Milt Epstein Applications Developer Graduate School of Library and Information Science (GSLIS) University of Illinois at Urbana-Champaign (UIUC) [email protected] -- 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
