-
- 24,544 Posts
I believe you. I just can't see any way it could happen.
I even moved the getProperty() code and the call to it to a separate snippet and it behaves just as it should. redirectToPrior is set as it should be, and if it's set, the http_referer is used in the URL, which is the only way they could be redirected back to the page they came from.
-
- 571 Posts
It is really intriguing! I have played around with all the things mentioned previously in this thread and none of them resolve the problem for me. The only thing that gets the behaviour I want is to set &redirectToPrior=`0`.
I think I will leave it as it is. Thanks for checking it out!
I looked at what Chrome thought the http_referer was each time I tried to visit the protected page and login. In all cases, Chrome (console document.referrer) showed that whether I had &redirectToPrior set to 1 or 0 the http_referer was the original protected url that I had tried to access from the email link at all stages of the process.
But here is an interesting thing that might shed some light on things. Not that I really understand it!
If you do both the things listed below, the default behaviour of Login is to redirect you to the page that you were originally trying to visit.
1. Remove the zero from the loginResourceId in the Login snippet properties, so this field is empty
2. Do not use &redirectToPrior at all on your page.
So could it be that the loginResourceId property being set to zero (it's default - redirect to self) tells &redirectToPrior that the HTTP_REFERER is actually the login page?
-
- 24,544 Posts
I can't make any kind of sense out of that, but thanks for all the testing.
-
- 18 Posts
&redirectToPrior=`0` WORKS -> I have banged my head for the last year trying to get this to work (here and there) and just gave up.
Thank you Andy!
-
- 571 Posts
What version of Login are you using? On the site where &redirectToPrior=`0` resolved the problem I was using version 1.9.5. I see that the latest version is 1.9.7.
-
- 24,544 Posts
I just stumbled back onto this thread. I wonder if redirectToPrior fails when the originally requested page is not accessible due to permissions. If that's the case, MODX acts as if the page doesn't exist and forwards the user to the error page.
If I'm right, making the page accessible but protecting it with a custom snippet that forwards users to the login page may make redirectToPrior work correctly (or not -- if sendRedirect doesn't set the referer properly):
/* CheckForLogin snippet */
if (! $modx->user->hasSessionContext($modx->context->get('key'))) {
$loginPageId = '12'; // change to ID of login page
$url = $modx->makeUrl($loginPageId, "", "", "full");
$modx->sendRedirect($url);
}
☆ A M B ☆