I found and interesting problem: I am using auth package, and Response::redirect_back when there is an error, or permission denied.
The use case: I click on a link after some time (the session is expired) and the auth logs me out. I store the URL in get param and redirect to the login page. When I login I redirect the page to the previous page, but if there is an error or permission denied, it tries to redirect back to the referrer which is currently the login page which redirects to the actual page, which redirects back...and so on. So it is an infinite loop.
How could this be solved? Can I explicitly set the referrer or use the fallback passed to redirect_back if the referrer is the login page?
That is the danger with redirecting in general, not specifically with redirect_back().
You could set a session var (not a flash var) before redirecting in login, and check before you redirect if it exists, which would indicate you're looping?
This is what I want to do either with session var or header. But I want to do the check in the redirect_back.
Also, I don't really understand why you highlighted "not a flash var". I think I only need this information (use fallback instead of referrer) for one request. This is why I wanted to send a header instead of session.
A flash var expires after page load, so it's gone when you redirect. So if you want to detect a redirect loop (= two redirects), it can not be used.
If you want to use a header, it needs to be set client side (because it has to be incoming), which requires custom JS.
It is probably better to avoid the loop. If you arrive at your login method, and you are already logged in, check the referrer, to see if you came from a real "login" link. If not, it was a redirect, and you can display an "access denied" message.
My problem is a bit different, but the use case you described is real.
1. I d some work. 2. I am hungry, so I get some food (x minutes, session expires), but I am on a page. 3. I am back. I continue working: click on a link on the same page, as I am only "logged out" in the background. 4. The new page (the link I clicked) redirects me to the login page with an url param including the previous page. 5. I log in, and the login redirects me to the previous page. 6. The page loads, but it is just a status set action, so it redirects me to the referrer (login in this case, normally the page I came from) OR the fallback url. 7. The referrer is the login page with the url param. I am logged in, so I am redirected to the page. 8. Loop of step 6 and 7
If I set a flash_var in point 5, and redirect_back checks that it should not redirect back to referrer, but to the fallback, then I can redirect to "a-page-related-to-my-current-progress" because the fallback is somehow connected to it (probably not the same page I came from). This is one redirect after the flash_var is set, and I can avoid the loop.
In to be general: this is just one use case. There can be other cases (not just login) where redirecting back would cause a loop. This is why I hate to use it, but telling it not to use the referrer could solve this. Anyone who uses redirect_back now without fallback also gets into a loop in the cases we described, so instead of a loop they are redirected to the base_url, if a fallback is not set.
The problem here is that when you get to step 6, your original "previous" page is lost, so you need to - store your version of a previous page somewhere - have a custom redirect_back that uses that first, referrer next, fallback last
This is quite application specific, I don't see a clean core implementation for this.
Donate
