This is purely my very opinionated 2¢ ... I've had to integrate against oAuth a few times, and have constantly found it a hassle.
The existing 'core' Python libraries for it are rather scattered in terms of active development, maturity and "street cred" ( by which I mean that you'll often find a big name website saying "You should use this library for oAuth against our API!", yet that library is badly documented, barely functional, often really out of date with current specs , and ships with a bunch of its own tests which it won't even pass ). I've seen a handful of oAuth plugins and "micro-frameworks" for django or uwsgi servers too. They try to be a complete plug&play solution, but then you have to worry about integrating the endpoints, skinning the views, and persisting the data. After a few minutes of playing with the modules -- if your app doesn't meet the exact specs/design requirements of these plugins, you're looking at a huge mess and really unattractive option. So for general feedback, I would suggest this: 1- make a core oAuth library that just works , is up to date , and is designed to easily integrate against 2- create a reference Pyramid/etc implementation of the client and server functions ( ie, like your sample views ) 3- create a bunch of helper functions that aid in setting up the above , which people can just call if they're lazy. Using SqlAlchemy as a datastore is a neat feature , but there are 2 red flags to me: - it doesn't look like i'll ( easily or at all ) be able to override your tablesnames or database structure - i'm now limited to sqlalchemy supported databases. if i'm on mysql/postgresql/oracle, that's fine - but if i'm using a mongodb or similar datastore -- forget it. I would, personally, prefer to have some sort of "config" object that I can pass in - which defines/provides some callbacks for searching and storing data. Having a drop-in capability and default settings of sqlalchemy are both fine –- but relying on it? that seems too much like rails/django and all that standardization/configuration restrictions which are a huge part of the reason why people choose Pyramid , Flask, or other frameworks instead of Django. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/pylons-devel/-/n7cYxSmYBzsJ. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
