-
Notifications
You must be signed in to change notification settings - Fork 198
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
Comments
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! |
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. |
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, |
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? |
For Doorkeeper module just default it to https instead. |
Back on topic...
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. |
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.
The text was updated successfully, but these errors were encountered: