Insensible defaults in constructors about oauthlib HOT 3 CLOSED

Not very easy is mildly put considering this is still very much in development and I would not even consider it alpha as the api changes with almost every commit =) Well done on figuring it all out!

There will be a guide / tutorial / some docs detailing how to implement an oauth 2 provider and as you hint it would be a good idea to assert that the various classes are initialized correctly as to avoid weird errors down the road.

One example of api change is that I'm trying to move to inheritance by composition style (request validator) and avoid having to subclass just to override a method or two (save_token) but this is still not complete. The reason of the oauth 2 provider taking so long is a mix of very limited time on my side and the extreme flexibility of the protocol making an implementation that nicely support all of it tricky.

The seemingly insensible defaults stems from the defaults not imposing any specific grant type or token type on the developer and thus everyone is forced to actively pick them and supply them. This might change in the future depending on what people wish for...

from oauthlib.

I understand that it is hard to impose a specific grant type, but I guess we could impose that people insert something of their own rather than None right?

I'll see if I can make a sensible PR

from oauthlib.

I've update the provider quite substantially and begun working on some docs, readable at https://oauthlib.readthedocs.org/en/latest/server2.html#creating-an-oauth-2-provider

I'm playing around with the idea of having different pre-configured endpoints associated with certain grant types. Also, the constructor defaults are now gone as all arguments are required.

from oauthlib.