New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not redirecting to Moodle after logging in when "destination" is used in the login URL #43
Comments
This is a pretty involved problem that I hadn't noticed before. Basically, this works if Drupal/Moodle are being used in subdirectory mode, but not subdomain mode. This is because Drupal doesn't allow the destination url parameter to contain a fully qualified domain as a value (this is done to prevent a security vulnerability along the lines of an xss problem) This is probably going to have to be solved within both the moodle_sso module, and the drupalservices plugin at the same time. The question is, how involved should this get? I think ideally either the drupalservices plugin should submit the url of Moodle to the Drupal system during setup, or the admin should go to the Drupal plugin and define the domain. After that, the question is how much of the url should be passed, and if a different variable should be used. I'll have to ponder that a bit here. I can probably roll in a 'clean urls' fix that I've been asked about as well. |
This attempts to solve the problem of subdomain based installations failing to get drupal to redirect back to the moodle install after moodle hands the user over.
Okay, Since it turns out that my site is actually kind of affected by this, I took a first stab at solving this. The fix currently lives in the "2.x-2.x-fix_url_redirect" branch. Could you check that code out, and grab the latest build of the dev version of the moodle_sso plugin for your Drupal site? If your Drupal site isn't using the moodle_connector plugin, you'll need to set a value for the moodle url inside of Drupal (you can find the screen for this by going to admin/config/people/moodle_sso ). moodle will ask you to upgrade the drupalservices plugin, and a new checkbox/setting will appear asking if you want to use a custom redirect variable. The answer is yes :) Give that a shot & let me know how it goes! |
Nice! You work quick. So this seems to have made the redirecting part work, if I go to a course enrol link and am not logged in, I can click login then it'll shoot me to Drupal and once I've logged in I get sent back to the correct Moodle URL. But now it seems to have broken the force login option, I now have to actually click login on the Moodle site for it to log the user in. Also logging out of Moodle no longer logs the user out of the Drupal site. I tried both the 7.x-1.x-dev version of the Drupal moodle_sso plugin, and a clone of the master branch, but both seem to give the same issue. I thought it might be the cookie domain disappearing again, but I turned debugging on, and the cookie domain is showing correctly on the Moodle login page |
Interesting, this should have no effect on either of those capabilities (and in fact, thats how I tested it over here). 'normal' operation is supposed to be that users are already logged in via Drupal by the time they arrive at Moodle. From there, when the Moodle 'force login' setting is set, if Moodle detects that a user hasn't been authenticated yet, it does a backend request to Drupal (not a front end one that would require a redirect). My first off-the-cuff guess is that the cookies you have for both Moodle & Drupal got munged somehow. Can you try logging out of both Moodle and Drupal, and then give it another shot? |
I looked in the Drupal site settings and in the Moodle auth plugin settings and the cookie domain seems to be all good there, exactly the same as when it was working. I tried logging out of Moodle and Drupal, then logging in to Drupal and then going to Moodle, but I still have to actually click the login button in Moodle every time. I had a go in Chrome and Firefox last night and then also in IE this morning and tried clearing all caches and cookies, definitely not working. I then tried to downgrade the Moodle plugin by copying over the files I made as a backup before I tried these new ones, but it gave me some "cannot downgrade" errors and wouldn't let me, so I can't go back and test just to make sure that it was these new plugins that did it, but it was working before I tried these. When I click login on Moodle it instantly logs the user in, so it's definitely picking up the logged in user from Drupal, it's just not forcing the login anymore. Sorry, I feel like I'm being a bit of a pain. |
The day a maintainer of a plugin/module thinks someone is being a pain for actually finding bugs and working with them to fix it is the day they should hand in their keyboard ;) You're fine, and this is super helpful! so just to confirm, you do have the force_login value checked, but for some reason it doesn't automatically make you logged in if you have previously logged in to Drupal? I'll take a look & see if I can at least get some debug code in that will help me diagnose this. Also, you can switch back to the 2.x-2.x-dev version, you'll just have to make one change in the database first. Find the table called "mdl_config_plugins", then find the record that has a plugin="auth_drupalservices" and name="version" just change the value field to equal "2014111400" and you'll be all set. |
Yep that's right. Ah okay, I thought I may have had to go change the version number, but didn't want to break anything with a database edit. I'll have a go at downgrading and see if everything works. |
Downgrading to the plugin versions that I was using before still doesn't work. Weird. Is there supposed to be a database entry for the force_login boolean to either be a 1 or a 0? I had a look at the mdl_config_plugins and can find values for the "special_goto" checkbox and the "call_logout_service" checkbox, but not the "force_login" one. |
force_login is actually a moodle system variable, and not specific to drupalservices. you can find the value for it in the mdl_config table rather than in the mdl_config_plugins table. Once you update the variable in the database you usually (but not always) need to purge the moodle caches for it to take. not sure why its erratic like that. |
Something else to check, the forcelogin variable is supposed to force it no matter whether you are looking at a course or a site page/area. I don't know the moodle 'api' very well, but I guess it could theoretically be possible that other areas don't respect the forcelogin variable, and possibly allow for non-logged in users regardless of the forcelogin setting. I know there's a "require login for courses" setting somewhere, and I just found a "force login for profiles" setting. maybe there's another one for your specific area of issue? Can you poke around a bit and see if there's maybe a setting like that? also, if you turn the debugging mode to "developer" you'll see a ton of good output messages that will probably help us debug this too. |
Ah damn! My bad! By looking in that table I figured out what my issue was... Just before I installed the new plugin I had turned on the "Auto-login guests" option, as it was the only way I have managed to be able to get non logged in users to be able to see the enrol.php pages without being logged in, so that they can view the course summary before purchasing. So now, with the auto login guests option off it all works fine again. I'll have to find another way around showing the enrol page to visitors, unless you can think of a way to allow the SSO auto login to still work with auto-login guests enabled. |
I've never heard of the auto-login guests thing, but they sound mutually exclusive to me. by saying force-login you are saying no users should see anything w/o being Drupal authenticated first (thus, no 'visitors' to worry about). whereas the auto-login guests thing sounds like it is saying treat anonymous guests as authenticated users - which shouldn't happen with forcelogin set - right? |
Yeah, I'm guessing it'd really tricky to get them working together. Basically anyone who isn't logged in gets logged in with a guest role, but then they also still have the login button, so it's a weird kind of "logged in". I'm not too worried about getting them to work together though, I just commented out these lines in my enrol.php file and it's giving me kind of the functionality that I want: if (!isloggedin()) {
// do not use require_login here because we are usually coming from it,
// it would also mess up the SESSION->wantsurl
redirect(get_login_url());
} |
it sounds more like you are just giving the anonymous user a guest role that does a little more than normal. Does some kind of user account also get created for these guest users? |
Nope, no user account gets created, so yeah, actually, it does seem like it's just promoting the visitor role a bit. But then there's the fact that it does reference the setting as "auto-login" and it does stop the other auto-login from firing, so it must do some sort of logging in, maybe. |
Another quick question, I've almost got it working exactly how I want thanks to your awesome fixing skills. Because I am sending users directly from Drupal to Moodle to URLs like "http://study.example.org/enrol/index.php?id=2" Is there some function I can run at the top of the enrol.php file inside the "if (!isloggedin()) {" part, that will try to check for a Drupal session and do a log in? Because at the moment it just does a redirect to the login page. Just looking in the drupalservices/auth.php file, would I just have run the "loginpage_hook()" function? I think I can see some stuff in there that I may be able to pull out and chuck up inside the !isloggedin check. Never mind about this one - I figured it out. I did it with this at the top of the file: if (!isloggedin()) {
$authplugin = get_auth_plugin(drupalservices);
$drupalsession = $authplugin->get_drupal_session();
if ($drupalsession != null) {
redirect(get_login_url());
}
} |
…s. Removed the 'use special goto' option
I made a couple of changes to this branch (unrelated to the auto-login problem). Could I get you to test this code out before I call this fixed? Basically I dropped the "use special redirect" field, and added a url argument that tells Drupal that the destination is a moodle url. It's a lot cleaner this way and regresses better for people using the old version. You'll need to update from the special branch for now, and update the moodle_sso module in drupal too. This should be the last change before I merge it in to master and 2.x-dev. |
Yep, this redirects perfectly! Every second time I click the log in button on Moodle it will work and send me to Drupal to log in with the moodle_url on the end like it's supposed to , but every other time it will send me just to "http://study.example.org/login/index.php" (study.example.org being my Moodle URL) and obviously I can't login with a drupalservices user there. An example of the issue: It happens every second time, and the first time always seems to go to Moodle. Interestingly, when I do get sent to Moodle's login page, and refresh that page, it will send me to Drupal to log in. |
I'm going to mark this as fixed and merge it into master & 2.x-2.x-dev. Thanks for the help in testing and fixing this! |
When I go to a Moodle page that requires logging in, it does send me back to drupal with the destination at the end of the URL, e.g.:
Moodle is on study.example.org
Drupal is on dev.example.org
http://dev.example.org/user/login?destination=course/view.php?id=2
So that part is working.
And then I'm guessing that once you've logged in it's supposed to send you to the Moodle URL with the destination appended, but this doesn't happen for me. Once logged in, it will send me to the Drupal URL with the destination appended.
So when logging in with the above URL, I get sent to:
http://dev.example.org/course/view.php?id=2
And that just gives me a page not found error.
I can find where the auth.php file appends the destination URL, but not where it's supposed to redirect it to after logging in, is this not fully implemented yet?
The text was updated successfully, but these errors were encountered: