Skip to content
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

Closed
sholladay opened this issue Feb 12, 2017 · 4 comments
Closed

Improve redirectTo behavior #154

sholladay opened this issue Feb 12, 2017 · 4 comments
Labels
breaking changes Change that can breaking existing code feature New functionality or improvement support Questions, discussions, and general support

Comments

@sholladay
Copy link
Contributor

sholladay commented Feb 12, 2017

The redirectTo feature is great, but it is way too eager to activate and does not respect the auth.mode of routes.

From the docs:

Note that using redirectTo with authentication mode 'try' will cause the protected endpoint to always redirect, voiding 'try' mode.

And also:

redirectOnTry - if false and route authentication mode is 'try', authentication errors will not trigger a redirection. Requires hapi version 6.2.0 or newer. Defaults to true

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 is required.

Currently I have to add this to every single route where auth is optional.

plugins : {
    'hapi-auth-cookie' : {
        redirectTo : false
    }
}

I'm failing to think of a scenario where I would want redirectTo and optional / try together. But if there is one, it is definitely not the common case.

I propose that redirectTo only triggers for required auth. We could have a redirectOnTry: 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 the redirectOnTry option at all.

sholladay added a commit to sholladay/hapi-auth-cookie that referenced this issue Feb 12, 2017
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.
@jaw187
Copy link
Contributor

jaw187 commented Feb 17, 2017

@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?

@jaw187 jaw187 self-assigned this Feb 17, 2017
@jaw187 jaw187 added feature New functionality or improvement question breaking changes Change that can breaking existing code labels Feb 17, 2017
@sholladay
Copy link
Contributor Author

sholladay commented Feb 17, 2017

there is a flag to override the behavior

There is no flag that fixes the redirectTo shenanigans for optional mode across routes. You could introduce a redirectOnOptional hack or just fix redirectTo. The latter is what PR #155 provides.

why should we eliminate it?

  • We should strive to eliminate any behavior that is confusing.
  • More importantly, we should respect auth mode and not duplicate its functionality.

@sholladay
Copy link
Contributor Author

This was fixed in #186. 😃

@Marsup Marsup added support Questions, discussions, and general support and removed question labels Sep 21, 2019
@lock
Copy link

lock bot commented Jan 9, 2020

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.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
breaking changes Change that can breaking existing code feature New functionality or improvement support Questions, discussions, and general support
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants