I like the proposal! My only concern is that providing a default implementation of the protocol from the library is already assuming application-specific implementation details. At that point, we are better of doing the return in the Plug.

I rather copy-paste the protocol implementation. I seem that concerned before in other libraries and it is frustrating to deal with.

I do like however the proposed implementation since having the protocol allows the the app to hook into the behavior they would like to see.

Being said, I am not sure, that is my general thought in the subject thus far.

Current implementation still allows you to handle it however you want. As far as my understanding goes, it just presets the status code that will show in the error_handler.

My understanding is that the flow is:

exception
|> protocol
|> plug error handler

So in the current version the connection is not halted. Merely derailed from succesful path into the error_handler.

Ok.. I am wrong. It halts the connection, and you dont seem to be able to change the code, only render errors.

What I've written in the strike through message seems to be true for the https://hexdocs.pm/plug/Plug.ErrorHandler.html, but Phoenix seems to only allow you to do the rendering of it.

I like the proposal! My only concern is that providing a default implementation of the protocol from the library is already assuming application-specific implementation details. At that point, we are better of doing the return in the Plug.

I rather copy-paste the protocol implementation. I seem that concerned before in other libraries and it is frustrating to deal with.

I do like however the proposed implementation since having the protocol allows the the app to hook into the behavior they would like to see.

Being said, I am not sure, that is my general thought in the subject thus far.

Per your proposal moved default impl code to documentation for anyone interested to paste in. Now that I worked with this for a bit, I see another issue with it. If you have two ueberauth apps inside single codebase, you cannot have different behaviour. That is highly unlikely to matter though.

If you have two ueberauth apps inside single codebase, you cannot have different behaviour. That is highly unlikely to matter though.

Yep, Ueberauth in general needs some love, rearchitect the library from bottom up to avoid these global configs as the first approach.

Sorry to bother you, do you mind updating the https://github.com/ueberauth/ueberauth/blob/master/CHANGELOG.md and bump the mix.exs version? It will help me to release faster.

Sure thing.

🚀 💜