Thanks for your great troubleshooting checklist/questions! Here's the best information I could procure quickly.
You are talking about CAS SSO?
- Yes, Yale's CAS for Single Sign-on
We have been using CAS for logins for about a year now and haven't had any type of looping.
- Interesting, we didn't notice it until we saw slowness and dove into the apache logs.
- Occasionally we'll see very high usage from a single IP if I run:
- cat /path/to/your/httpd/access.log | awk '{print $1}' | sort | uniq -c | sort -n
- grepping the access log on the IP with the most hits (or in the top 5) will sometimes show a series of requests to the pluginfile url mentioned above. You have to get lucky in terms of day you pick, since the problem only persists until the user closes his or her browser. I'm currently unable to replicate the problem, so I'm guessing here.
- Could you try looking for these loops if you have a live server?
- Since posting this issue, we've removed other bottlenecks in our system which have decreased the signficance of this problem.
Whats your config like?
- A few moodle app servers behind a hardware load-balancer.
- Multiple moodle versions/instances on each app server
- CAS and Database on separate servers.
Do you have all the correct certificates setup in Apache on the moodle server
* the CA-Bundle certificate
* your intermediary certificate, and
* finally the server certificate correctly.
- YES
Did you turn on HTTPS logins only in moodle?
- No, we require HTTPS for all pages, including login.
All your themes using URLs for linking or path linking?
- What's the difference between the two?
- How would this be related to SSO?
Within CAS you have the correct URL inputed, should resolve like so, https://login.bshp.edu/cas/login?service=https%3A%2F%2Fmoodle2.bshp.edu%2Flogin%2Findex.php
We also have turned on the feature to force all users to login and turned use HTTPs for logins in moodle, What do your cas.log and apache logs say?
- Both
Database or Moodledata sessions?
- File based sessions (moodledata)
Also another thing that can cause a loop is make sure that the session.save_path in php.ini where the sessions are stored is writable by the web server user.
- We don't have the session.save_path in php.ini or config.php. I'm going to rule this out for now, since I can see sessions being written to the appropriate moodledata sessions directory.
You can run into issues if you are storing the sessions in the database and the sessions folder in the moodledata directory was never created therefor php cannot successfully save the session information returned by CAS becuase the path is either invalid or not writable.
- Interesting, but not applicable with file based sessions.
Note 1: We are running a trimmed down version of the CAS plugin, it has not caused problems in the past.
Note 2: I can create very small loop if I disable cookies in my browser, but in this case the browser detects the loop and fails gracefully.
Thanks again for the questions. I'll keep looking.
