From the Goggle dev tools it looks like the login is just bouncing back and forth from the wordpress login to https://cas.tennessee.edu On other servers where I haven’t changed anything and use the same settings Authorizer and CAS log in continues to work fine.
Hm, it might be failing when the CAS client tries to find the ca-bundle.crt file (used to validate SSL certificates):
https://github.com/uhm-coe/authorizer/blob/master/src/authorizer/class-authentication.php#L753
Are you able to inspect whether the WordPress constants ABSPATH and WPINC are correctly pointing to the new location?
Also, a few lines down on the link above, you’ll see a commented out setDebug() call; you can try uncommenting that to output debug logs to wp-content/debug.log and see if there are helpful details in there. (You may want to change that path to something not publicly reachable if you’re doing it on a production server.)
https://github.com/uhm-coe/authorizer/blob/master/src/authorizer/class-authentication.php#L768
Finally, in your Apache config, do both DocumentRoot and the <Directory /path/to/wordpress> entry for WordPress point to the new location?
All my paths look correct, the old path isn’t in the Apache conf files or the wp database and the ABSPATH and WPINC haven’t been modified from the defaults.
One login attempt (that of course fails) generates 523 lines in the debug log. I assume that’s not normal, but I don’t know enough about CAS to know what I’m looking at.
I doubt this has any bearing on the CAS problem but an older site on the same server that’s using Authorizer with LDAP works with no problem.
Yeah, the phpCAS logger is super chatty. Let us know when you get a chance to review it, it should at least contain the warnings or failure conditions.
You can also anonymize it and send it our way, but that may end up taking more effort since it tends to contain lots of user information from the CAS server.
It does seem like your issue is specific to CAS; will be interested to see how it might be related to the system path changes!
I’ve put the log at https://volweb.utk.edu/~dgreene/cas-log I can’t really follow the logic to tell what’s happening. If you spot anything, the help is appreciated.
In that log I see a system path for curl’s ca-bundle.crt lookup:
CURL: Set CURLOPT_CAINFO /data/www/call.infosci/html/wp-includes/certificates/ca-bundle.crt [CurlRequest.php:129]
Does that look like a valid (new) path to you? If not, that might be the issue!
That’s the right path, I never have figured it out. I just moved the CAS authenticated sites off that server. The only sites left on that server are LDAP ones and they work fine.
