get_custom_mail gets stuck in a loop
| Project: | Shibboleth authentication |
| Version: | 6.x-3.3 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
the code to prompt the user for an email address gets caught in a loop. the first time through, it sets the session variables correctly (more or less) and does a drupal_goto to "shib_auth/get_custom_mail". which then runs shib_auth_init() again, and since there still is no email address (because the form hasn't even been displayed yet), it sets the session redirect URL variable to "shib_auth/get_custom_mail" and does a drupal_goto to redirect right back to itself again.
i think the second bit - about the redirect to where you are - is not actually so big of a problem, but it does seem unnecessary. mostly the problem is resetting the session variable, which loses the real path that you were trying to go to in the first place.
i have patched it to only set the session variable if it is not already set; to trim the "shib_login" prefix away from the path it does store (since we don't need to pass through that again as far as i can see, this may be incorrect); and to only do a goto redirect to the form if we are not already there. we have clean URLs enabled and i can't really test it without that setting (too much else on the site would break), so this may be making some wrong assumptions. but i think it's the right general idea at least.
| Attachment | Size |
|---|---|
| shib_auth.loop_.patch | 1.11 KB |
#1
The problem is, as far as I understand, that the module does too many redirects, but finally it displays well, unless forgetting the page, the user was coming from. Am I right?
The 'shib_login' part of the redirect is used to bypass caching.
#2
what also seems to be involved is one of the calls to session_destroy() - once that is run, setting $_SESSION does not actually set PHP session variables unless you explicitly restart the session - so the "saved" original path is thrown away.
i commented out the calls to session_destroy() and called the Drupal sess_regenerate() function instead and that along with the previous change seems to do the trick.