I've been trying to get the CAS module to work without much success so far. I installed the 6.x-3.x dev version because it uses the Libraries API (which is successfully finding phpCAS).
When I click "Login", I get sent to the CAS server, log in successfully, then get redirected back to mydrupalhost/cas, where it gets stuck in a redirect loop. I'm not sure what the cause is. Someone else reported a similar issue being resolved by upgrading phpCAS from 1.0.0 to a newer version. I've tried phpCAS 1.1.3 and 1.2.0 and encounter the same problem either way.
What can I do to diagnose the redirect loop problem? I'm not seeing anything interesting in the tomcat/catalina logs (except a new ticket being issued), probably because the login is succeeding from the CAS end.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 1086748-by-machrider-Getting-redirect-loop-on-.patch | 1.12 KB | bfroehle |
| #5 | cas-debug.txt | 21.79 KB | machrider |
Comments
Comment #1
machrider commentedJust tried it with cas-6.x-2.2 and got the same redirect loop after logging into the CAS server (and the login never completes on the Drupal side).
Comment #2
metzlerd commentedI'd recommend turning on logging in your cas module and inspecting the logs to see if there's more information there. That's how we tracked down the prior 1.0.0 issue.
Dave
Comment #3
machrider commentedI'm not seeing any new entries appearing in the dblog. Is there an option I have to turn on somewhere to make the CAS module log? I don't see anything like that.
Comment #4
metzlerd commentedYes, it is part of the phpCAS library and can be enabled from the CAS settings page in a setting called "CAS debugging output filename:". You do need to make sure that the log files are created in a place that the apache user has write access too.
Comment #5
machrider commentedAttached the log. The CAS server is at localhost:8443 and the Drupal site is at http://mysite/ which also happens to be the local machine. I'm not sure why phpCAS is redirecting to http://mysite/cas, is that a special URL that the CAS module handles to extract the resulting ticket and create/login the user?
Thanks for the help Dave.
Comment #6
metzlerd commentedLooks like you've got a problem with your php Sessions. phpCas is doing the redirect, to remove the ticket from the url and then when it gets back the session variable that it has set is gone. Could you be having some trouble with session initialization in your PHP environment?
You might further diagnose this using the examples that are provided in the docs folders of phpCAS.
Dave
Comment #7
machrider commentedThanks Dave, your suggestion was spot on. I think this occurred because of Pressflow (which I didn't realize we were using), which disables anonymous sessions normally. I solved it by inserting a session_start() call in cas_form_alter:
The entire login process works now. I'll have to play around a little more to make sure this is the right fix.
Comment #8
metzlerd commentedIf you feel comfortable, you might consider writing a helper module that has the session_start call in it... or better yet you could try doing this call in your settings.php file:
might work.
This way you aren't putting in a fix that will need to be updated when you upgrade the cas module. I'll do some checking about whether this should be something we should address in the cas module.
Comment #9
bfroehle commented(Of course you mean $_GET['q] == 'cas'...).
Drupal 7 has the lazy session loading and so we call drupal_session_start() [which in turn calls session_start().] Pressflow has a similarly named function.
I'm going to suggest that we do, in the same place as drupal_session_start() in the 7.x-1.x branch
if (function_exists('drupal_session_start')) {
drupal_session_start();
}
which should work in both D6 (which does not have the function) and PressFlow.
Comment #10
metzlerd commentedYes, or course, that is what I meant. Sounds like a good idea.
Comment #11
bfroehle commentedmachrider: Can you try out this patch (on top of 6.x-3.x) and see if it works? Thanks!
Comment #12
bfroehle commentedRetitling. Still would be great to get a test with this patch and pressflow. However, I'm pretty sure it'll work so I'm considering committing it regardless.
Comment #13
machrider commentedHi Bradley, sorry I guess I didn't get any notification of followups on this. I tried your patch and it seems to resolve my issue (with my one-line change removed). Thanks, it'll be nice to see this work without patches on my part!
Comment #14
bfroehle commentedCommitted to 6.x-3.x.
Thanks machrider!
Comment #16
penyaskitoSubscribing.
Comment #17
bfroehle commented@penyaskito: This has been marked as fixed. Are you still experiencing it?
Comment #18
penyaskitoI'll test it tomorrow, just commented for tracking it. Has this been included in 3.0-beta1 or do I need to use the patch?
Thanks for your help.
Comment #19
bfroehle commentedYes, it should be in 6.x-3.0-beta1 (or any development release since March 15th or so).
Comment #20
penyaskitoInstalled 6.x-3.0-beta1 and phpCAS 1.2.1 and I'm still experiencing the redirection issue. :-(
Comment #21
bfroehle commentedAnd you are on PressFlow? Can you turn on debugging and post a copy of the debug log?
Comment #22
bfroehle commentedNothing more to do here until we can get some more debugging information.
Comment #23
treksler commentedfix confirmed working with pressflow 5.23.50 and cas-5.x-4.0 (manually patched) with
thank you
Comment #24
bfroehle commented