Closed eoinkelly closed 4 years ago
Hi @eoinkelly, sorry for getting back to you so late. I think your proposal is really good. I think it's also best to use the canonical way to handle errors. Let me know if there's something I can help with. Cheers!
Background
The canonical way to handle errors in an OmniAuth strategy is to call
fail!(:some_label, some_exception)
- this method invokes the OmniAuthon_failure
hook which, by default, is the FailureEndpoint rack middleware.FailureEndpoint
redirects you to/auth/failure
which you must implement in your app. A common change to this is to replaceFailureEndpoint
with a different rack middleware which calls one of the controller actions in your app e.g.Current behaviour
Currently this gem returns values via the Rails
session
. The Realme FLT is insession[:uid]
if everything went well and the error is insession[:realme_error]
if not.The issues
This works fine but isn't really "conventional" for OmniAuth. There is also a potential edge case where the Rails app is using the session for other stuff and the error message we add tips it over the size limit of what can be stored in a cookie (4KB).
My proposal
I would like to deprecate using the Rails
session
to return values to the Rails app and instead use the conventionalrequest.env["omniauth.auth"]
. Below is a rough example of a controller from an app that receives values from this gem that way:Backwards compatibility
I don't want to break existing users so I propose keeping the old
session
functionality around in ause_session_to_store_results
option.You could then make a choice about whether that option defaults to true or not, perhaps in sync with a version bump.
Feedback I'd like
I'm happy to make a PR for this but wanted to run this past you first to make sure it's something you would be ok considering. Obviously the final decision is made based on the look & feel of the PR.