Thanks for the very clear writeup of your problem.
We’ve done similar things and I seem to recall encountering similar issues.
Is there some issue with HTTP vs. HTTPS URLs? This is a frequent source of authentication issues e.g. when you come from Wordpress, you’re on the secure site, but when you open a new tab, you’re on the insecure site.
What happens in the following scenario?
- User opens the LMS login page (https://lms.example.com/login/)
- User enters their credentials to log into the LMS
- User visits the WordPress home page (https://wordpress.example.com/)
- User clicks login
- Now user should immediately be logged in to Wordpress
- Now, if the user opens the LMS link in the new tab, they should still be logged in there too
From the initial finding, we found that logged in cookies are set but in request, we are getting anonymous user .
Hmm, so either the cookie is invalid (it has expired, or a newer cookie has been issued, the session cache was cleared, or the user was logged out), or the cookie isn’t sufficient to authenticate the user. But from some quick tests, it seems like only the
sessionid cookie is required for the user to access the LMS dashboard. So likely the cookie is invalid.
Is it possible that wordpress is somehow overwriting the Open edX
sessionid cookie when the user returns to Wordpress? Since they are running on a common domain, that is one possibility.
There is an easy(ish) way to test if the problem is Wordpress or the LMS. When you are entering credentials on the LMS login page, shut down wordpress so it’s not running. Then continue logging in to the LMS. You’ll be redirected to wordpress, but wordpress won’t load. Now return to the LMS. Are you still logged in?
If none of those work, can you compare the cookies that get set when logging in “directly” to the LMS vs. when logging in via Wordpress? Is there any difference?