Authenticate status code redirect option

[danielcorin]

trafficstars

[coveralls]

Coverage remained the same at 100.0% when pulling cd69e25b877a7dd165444272d912f6a025065136 on danielcorin:dc/auth-status-code-override into 1ac8cbba5aef89845c959d543a248bbb647105c2 on jaredhanson:master.

[coveralls]

Coverage remained the same at 100.0% when pulling cd69e25b877a7dd165444272d912f6a025065136 on danielcorin:dc/auth-status-code-override into 1ac8cbba5aef89845c959d543a248bbb647105c2 on jaredhanson:master.

[CoreyKovalik]

:+1: @jaredhanson

[korenzerah]

Waiting for this feature! When will it be merged? @jaredhanson

[NullSoldier]

@jaredhanson is this going to get merged, what needs to be done here? Do you want me to take it over to do something here??

[jaredhanson]

For those asking for this to be merged - can you please provide rationale? Why would you want a status code other than 302 when redirecting to an OAuth server?

[danielcorin]

It's been a while since I looked at this PR but if I'm understanding the spec correctly, the returned status code is considered an implementation detail, so providing flexibility would be within the bounds of an OAuth 2.0 library to support. I could imagine an implementation potentially returning a 301 instead of a 302 in the HTTP redirect case as well as a non-3xx if the app chose to handle the redirect mechanism using something other than HTTP.

[jaredhanson]

Thanks @danielcorin. I realize there is flexibility in the spec, but I'm looking for actual functionality that requires a non-302 redirect, and thus a changes to the implementation in this module. I don't want to support code that could, in theory, be used but in practice is not.

[korenzerah]

@jaredhanson The reason we needed to use another statusCode is because we had to handle the browser redirect by ourselves on the client-side (React SPA web app). We couldn't do that with a 302 redirect option.