-
Notifications
You must be signed in to change notification settings - Fork 100
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
Improve redirectTo behavior #154
Comments
Fixes hapijs#154. Because redirecting preempts the original route handler to protect it from unauthenticated requests, it doesn't make sense to redirect when routes explicitly want to process unauthenticated requests.
@sholladay As noted in the PR, I worry about users that expect this behavior. Since there is a flag to override the behavior, why should we eliminate it? |
There is no flag that fixes the
|
This was fixed in #186. 😃 |
This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions. |
The
redirectTo
feature is great, but it is way too eager to activate and does not respect theauth.mode
of routes.From the docs:
And also:
This is all needlessly silly and complicated. I bet at least 95% of the time what people want is for
redirectTo
to only affect requests whose auth mode isrequired
.Currently I have to add this to every single route where auth is
optional
.I'm failing to think of a scenario where I would want
redirectTo
andoptional
/try
together. But if there is one, it is definitely not the common case.I propose that
redirectTo
only triggers forrequired
auth. We could have aredirectOnTry: true
to re-enable the old behavior, but it's still a breaking change. And with the new behavior, I'm not sure anyone actually even needs theredirectOnTry
option at all.The text was updated successfully, but these errors were encountered: