search

songkick / oauth2-provider

Simple OAuth 2.0 provider toolkit
MIT License
528 stars 148 forks source link

Will this work with Mongoid? #35

Closed adpande closed 12 years ago

adpande commented 12 years ago

Hi songkick,

I want to use this with mongoid 3 orm. Will it work with that?

Regards, Abhishek

josephwilk commented 12 years ago

Its currently written against ActiveRecord but that is just a data store so no reason it could not work with Mongoid aswell. Fancy having a go at writing a patch?

Thanks,

jcoglan commented 12 years ago

It's been on my mind to put an API between the protocol layer and ActiveRecord, because of some things we need to do on our own stack.

adpande commented 12 years ago

I can give a try. Can you tell me were I can start and your thoughts on implementing this?

jcoglan commented 12 years ago

Basically, there are currently two main sets of classes, the namespaces OAuth2::Provider and OAuth2::Model. The former, which deal with the wire protocol, talk directly to the latter, which mostly deal with persistence although there are security and protocol concerns probably leaking in there a little bit.

The Provider classes should instead talk to an object with an abstract API that can be swapped out. The default such object would be based on the current ActiveRecord implementation, but could be replaced by any object with an equivalent API.

jcoglan commented 12 years ago

Thinking more long-term, this should not simply abstract the functionality provided by ActiveRecord, but accomodate places where the spec allows you to make different decisions than what we've done. For example using different token types, or using self-contained rather than referential tokens.

We aren't going to move past draft-10 until the spec is finalized, though, so I might be getting ahead of myself here. Point being, if we're opening up a new plugin API we need to think very carefully about it.

andrewpbrett commented 12 years ago

If anyone wants to take a look as a starting point, I have a fork that's using MongoMapper. I haven't had a chance to think about what it would look like to further modify it so that it could be merged in and left to the user as a config, but FWIW:

https://github.com/andrewpbrett/oauth2-provider/commits/master

josephwilk commented 12 years ago

Great thanks Andrew!

jcoglan commented 12 years ago

Closing for now, since I'm trying to get the to-do list closed up so we can release a gem. Having begun work on some migration stuff in our code, I've decided we're not going to do an abstract model layer since we don't need it. If you want to go ahead with such a project, open a pull request when you're done.

neiltron commented 11 years ago

I've converted @andrewpbrett's fork to work with Mongoid. I haven't fully tested it but it seems to be working pretty well so far.

http://github.com/neiltron/oauth2-provider

jcoglan commented 11 years ago

Has anyone tried to do this by introducing an adapter API that the protocol layer talks to, and having various persistence APIs that implement said API? Having a fork that hard-codes the protocol classes to talk to Mongo makes it harder to merge in protocol-level bug fixes.

neiltron commented 11 years ago

I would love for that to happen but didn't have time on this project. I'm sure I'll be using this lib more in the future, though, so I'd like to help contribute towards that goal if I can.

neiltron commented 11 years ago

Bump. If someone else creates the adapter API, I'd be glad to help with it and maintain the Mongoid adapter.