-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
FailureApp overwrites redirect status with Devise.responder.error_status #5570
Comments
That's interesting, I guess we never considered recall being used like that. There was someone else who stumbled upon this change due to another usage with redirect here: #5561, they were actually redirecting from the controller (rather than explicitly recalling like you did) and expecting recall to honor it. I guess we could possibly set the response to one or the other configured status, depending on what the recall app gives us back. (e.g. if it's a 3xx we use the configured Is the
Yeah this is inline with what I mentioned above, I could see a change like this happening possibly.
It needs to, in order to be fully compatible with Turbo (ensuring a compatible response, I mean). I tried explaining a little bit about the reasoning in that other issue: #5561 (comment), but the overall idea of recalling was to simulate re-rendering the form with the authentication failure, thus responding with an error status like any other Rails controller would do. |
We use I could set up a PR which uses either |
It appears some people use the recall functionality with a redirect response, and Devise starting on version 4.9 was overriding that status code to the configured `error_status` for better Turbo support, which broke the redirect functionality / expectation. While I don't think it's really great usage of the recall functionality, or at least it was unexpected usage, it's been working like that basically forever where recalling would use the status code of the recalled action, so this at least keeps it more consistent with that behavior by respecting redirects and keeping that response as a redirect based on the configured status, which should also work with Turbo I believe, and makes this less of a breaking change. Closes #5570 Closes #5561 (it was closed previously, but related / closes with an actual change now.)
It appears some people use the recall functionality with a redirect response, and Devise starting on version 4.9 was overriding that status code to the configured `error_status` for better Turbo support, which broke the redirect functionality / expectation. While I don't think it's really great usage of the recall functionality, or at least it was unexpected usage, it's been working like that basically forever where recalling would use the status code of the recalled action, so this at least keeps it more consistent with that behavior by respecting redirects and keeping that response as a redirect based on the configured status, which should also work with Turbo I believe, and makes this less of a breaking change. Closes #5570 Closes #5561 (it was closed previously, but related / closes with an actual change now.)
@devdicated I see, yeah I'm not sure off the top of my head how to make flash + warden redirect work, there's probably some incantation, I'll give it some thought, but what you explained makes sense.
Sorry I missed your message previously, I was working on making that change here: #5573. Hopefully that's all we need to have redirects when recalling the app / action working, making this less of a "breaking" change. Let me know what you think. (or if you have an opportunity to test it) Thanks! |
It appears some people use the recall functionality with a redirect response, and Devise starting on version 4.9 was overriding that status code to the configured `error_status` for better Turbo support, which broke the redirect functionality / expectation. While I don't think it's really great usage of the recall functionality, or at least it was unexpected usage, it's been working like that basically forever where recalling would use the status code of the recalled action, so this at least keeps it more consistent with that behavior by respecting redirects and keeping that response as a redirect based on the configured status, which should also work with Turbo I believe, and makes this less of a breaking change. Closes #5570 Closes #5561 (it was closed previously, but related / closes with an actual change now.)
It appears some people use the recall functionality with a redirect response, and Devise starting on version 4.9 was overriding that status code to the configured `error_status` for better Turbo support, which broke the redirect functionality / expectation. While I don't think it's really great usage of the recall functionality, or at least it was unexpected usage, it's been working like that basically forever where recalling would use the status code of the recalled action, so this at least keeps it more consistent with that behavior by respecting redirects and keeping that response as a redirect based on the configured status, which should also work with Turbo I believe, and makes this less of a breaking change. Closes #5570 Closes #5561 (it was closed previously, but related / closes with an actual change now.)
we're also facing to the same problem. |
Yeah, your fix works well. |
Thanks for confirming. I'll get that merged & release a new version soon. |
Hi, I use the devise FailureApp to redirect to a multifactor authentication page if the user has set up their account with MFA. The following code works as expected in 4.8:
In the strategy
In Devise::MultifactorController
Environment
Current behavior
The 4.9.0 version of the failure app overwrites the response code from the recall with
Devise.responder.error_status
:Expected behavior
If the response code is a redirect, don't overwrite the status or use
Devise.responder.redirect_status
. It could be that I am misunderstanding or misusing the Failure app, but it seems to me that a redirect status from the recall app should never be overwritten with a client error status.The text was updated successfully, but these errors were encountered: