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