dvv / social

Cowboy handler for social login via OAuth2 providers
MIT License
44 stars 14 forks source link

Getting the access/refresh code from within Erlang #2

Closed jtmoulia closed 10 years ago

jtmoulia commented 10 years ago

Hey, I have an Erlang application for which I'd like to use social to navigate the oauth flow, but when the server receives the callback request with the code query param, I'd like to write the code to a database for future use.

From the readme, I can see how to get the code using javascript, but not from within Erlang itself. Is this possible?

Thanks -- impressed with the dead simple cowboy integration!

dvv commented 10 years ago

I believe you'd better go with another middleware right beneath social, which would check presense of the code. Or you may add logging below https://github.com/dvv/social/blob/master/src/cowboy_social.erl#L175. Does this help?

yw, --Vladimir

jtmoulia commented 10 years ago

Thanks for the response! What would you think of being able to configure a social provider, e.g. Google, with an optional post-callback hook? It could be called at the line you referenced, https://github.com/dvv/social/blob/master/src/cowboy_social.erl#L175. I think it would make sense for the function to accept post/3's return, e.g. fun(TokenProps, Req), and have the same return type.

The hook could be a function (straightforward), or module implementing a middleware like behavior.

I can write it and add a pull request to this issue, but I was curious what your opinion is.

dvv commented 10 years ago

I would still go with separate middleware here, as the case in point is not so common. However, it's imo good not to proliferate unnecessary forks so let's look at your patch ) Please, try to be generic

jtmoulia commented 10 years ago

Hey, two reasons the middleware route was throwing me:

  1. It wouldn't allow me to take advantage of the check_code/2 function being called by the REST handler.
  2. Cowboy is running other HTTP services in my application, and I didn't want to add global middleware (I think all middleware is global?)

Also, I totally get not wanting to support unnecessary configuration, but in my work on persistent backend services needing to save the tokens for future use is a pretty common use case. I may have a niche viewpoint tho :)

If you think this is an alright direction, I'll add documentation. Thanks!