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

Add generic provider support #230

Open
arcreative opened this issue Mar 21, 2016 · 6 comments
Open

Add generic provider support #230

arcreative opened this issue Mar 21, 2016 · 6 comments

Comments

@arcreative
Copy link

I think it's great that you've added so many default providers to this module, but it's really really lacking a generic implementation for both implicit and code grant types. Many times, all that needs to change is the authorization URL, but we can't fix that because it's been hardcoded. I feel like that would save you a lot of time implementing for every provider under the sun when in most use cases it simply would mean passing one more parameter (the URL) to the module call. Furthermore, your other plugins could implement this generic/abstract plugin if the implementation is simple enough (which most appear to be).

I'll see if I can work up a pull request, but for the time being, I've had to move on to implementing my own solution.

@nraboy
Copy link
Owner

nraboy commented Mar 21, 2016

Believe me I want this to happen. The problem I faced was that certain implicit grant providers insisted on straying slightly away from the spec.

I'm away from my computer right now but I think Facebook was one of them.

Explicit grant providers are much more difficult than implicit.

Totally open to a pull request if you cook up something awesome!

@arcreative
Copy link
Author

Hah, not surprising, seems like everyone happily comes up with their own way of handling the spec :-)

My particular use case is using doorkeeper as a provider, maybe the temporary solution is to just to create a new plug for that while finding a broader solution for the others.

@nraboy
Copy link
Owner

nraboy commented Mar 21, 2016

Open to a PR on Doorkeeper if you make one in the short term.

Thanks to the contributors, this library has become a heck of a lot better and easier to maintain than it used to be.

Best,

@arcreative
Copy link
Author

On that note--Doorkeeper production defaults don't allow non-SSL redirect endpoints (thus, http://localhost/callback wouldn't be valid). Do you know of a workaround for that on this repo's end, or would it just have to be disabled on the provider's end?

@nraboy
Copy link
Owner

nraboy commented Mar 22, 2016

For Doorkeeper module just default it to https instead.

@joaomatossilva
Copy link

Back on topic...

The problem I faced was that certain implicit grant providers insisted on straying slightly away from the spec.

This shouln't be a reason for not existing a generic provider. The generic provider should be stric to the spec. In that way if the service follows the spec, very well, if not, then it should implemented as a specific one with the scpeific deviations.

It's a big limitian on the library not having a generic provider to be able to connect into also custom made or private auth services.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants