Grape Integration

[maclover7]

Any suggestions on how to implement with the Grape API framework?

Specifically, I'm looking to see how I can use the doorkeeper_authorize! method, but Grape isn't powered by controllers, just a .rb file.

[tute]

@maclover7 see related project: https://github.com/fuCtor/grape-doorkeeper

And see (somewhat) related issues:

• Compatibility issue with Grape #339
• dropping legacy doorkeeper_for and welcome doorkeeper_authorize! #448 (diff)
• Doorkeeper conditionals allow all requests without token in Grape #426
• Add skip_doorkeeper_for (and other refactors) #434 (comment)

I didn't try to integrate it with Grape myself, so I don't know what problems will arise. Another place to look for people doing this is https://stackoverflow.com/search?q=doorkeeper+grape.

I would be happy to discuss refactors that wouldn't change Rails behavior, but would make it easier to integrate with Grape.

Thanks for your question.

[hobofan]

I gave it a shot and got it to work for my limited requirements via a mixin, built after the already existing Rails helper. A few pain points are mentioned in my PR.

As for refactors, if Doorkeeper would only rely, or provide a fallback to Rack::Request, integrations for other frameworks should be pretty trivial. (e.g. two access_token_methods rely on the existence of Request#authorization which is only provided by ActionDispatch::Request)

[sethherr]

After running into many issues with grape_doorkeeper, I'd strongly recommend wine_bouncer instead for the integration of grape and doorkeeper (it assumes you've mounted grape in a rails application)

[tute]

wine_bouncer looks good, thanks for your suggestion @sethherr.

I'd love to see a wiki page explaining doorkeeper can be used with Grape through That project.

Closing as this seems to solve the issue, happy to continue further discussion. Thank you all for your input.

[hobofan]

I saw and tried wine_bouncer and it works well, but I think it's too "heavy" for "just" connecting Grape and Doorkeeper. I wrote the helper as a more lightweight solution.

I'd love to help in detaching Doorkeeper from the Rails internals and making it more open for other frameworks, but I'm pretty tied up with work at the moment.

[sethherr]

Added Doorkeeper and Grape wiki page and link to wiki page in how-to.

Opening an issue for a sample app.

[tute]

Thanks!

[antek-drzewiecki]

Hi @tute , i'm also looking for a more elegant way to remove doorkeeper authentication logic from my gem wine_bouncer. Currently i'm implementing the doorkeeper_authorize! @ source, a huge API breaking potential since it relies on several Doorkeeper methods.

All it does is converts an rack request to an action dispatch request. Then it tries to create an token and authorises it. It would be useful to have the method doorkeeper_authorize!(token, *scopes) method not relying on Grape or an ActiveSupport::Concern, so i can properly pass the two dependencies to the authorization method.

[tute]

Hi @antek-drzewiecki, thanks for your response.

I recently refactored the object that defines doorkeeper_authorize! (db9c00f), to make it extra clear where's the framework specific code. I believe the only dependency on a framework is used in doorkeeper_render_error_with(error). It also uses request somewhere else, but I'm pretty sure any Rack request will work.

If this is true, almost all that file is not Rails specific, and the only part that should be configurable per framework is the actual response part. This implies doorkeeper_render_error_with(error) should belong to the public interface, be considered stable, and the only part you would need to redefine.

I could further refactor to make it clear in code what is happening (all is framework agnostic, and you can define how to build the response object in X place).

Does it make sense to you? Would you like us to work together towards that?

[tute]

Status update: just merged Grape integration into master: #567.