Skip to content
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

Closed
Cheesenbizkitz opened this issue Dec 30, 2014 · 19 comments
Assignees
Labels
Milestone

Comments

@Cheesenbizkitz
Copy link

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?

@netw3rker
Copy link
Collaborator

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.

netw3rker added a commit that referenced this issue Dec 30, 2014
 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.
@netw3rker
Copy link
Collaborator

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!
Thanks

@Cheesenbizkitz
Copy link
Author

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

@netw3rker
Copy link
Collaborator

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?

@Cheesenbizkitz
Copy link
Author

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.

@netw3rker
Copy link
Collaborator

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.

@Cheesenbizkitz
Copy link
Author

Yep that's right.
I've got force_login checked. I have tried unchecking it, saving it, then re checking it in case it hadn't stuck or had changed it's value in the database, but that didn't help.
Also logging out of Moodle just sends me to the home page of Moodle and doesn't log me out of Drupal anymore.

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.

@Cheesenbizkitz
Copy link
Author

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.

See attached screenshot:
mysql_values

@netw3rker
Copy link
Collaborator

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.

@netw3rker
Copy link
Collaborator

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.

@Cheesenbizkitz
Copy link
Author

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.

@netw3rker
Copy link
Collaborator

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?

@Cheesenbizkitz
Copy link
Author

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".
So the force_login doesn't do it's thing because they're technically logged in already when they hit the site, but then hitting the login button will fire the Drupal Services login.

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());
}

@netw3rker
Copy link
Collaborator

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?

@Cheesenbizkitz
Copy link
Author

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.

@Cheesenbizkitz
Copy link
Author

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"
They get there, see the course info, then get asked to log in at the bottom to purchase, they hit log in, go to the Drupal site, they log in and it now successfully redirects them back to that same Moodle page, but it seems as though the function that forces login doesn't actually fire on that page so they are still not logged in, probably because it was designed for a user to already by logged in once they get there.

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());
}
}

netw3rker added a commit that referenced this issue Dec 31, 2014
@netw3rker
Copy link
Collaborator

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.

@Cheesenbizkitz
Copy link
Author

Yep, this redirects perfectly!
Except I have one last issue that may or may not be related to this.

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:
I'm on the Moodle site, not logged in to Drupal, then I click log in on Moodle, it'll then send me to Moodle's log in page, if I then go back a page and click log in again, it'll send me to Drupal like it's supposed to, then if I go back a page, back to Moodle and click log in again, it'll send me to Moodle's login page and continue like that if I keep going back to log in.

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.

@netw3rker netw3rker added this to the 2.0 release milestone Jan 6, 2015
@netw3rker netw3rker added the bug label Jan 6, 2015
@netw3rker netw3rker self-assigned this Jan 6, 2015
@netw3rker
Copy link
Collaborator

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants