Look at the document of Flask-OAuth http://packages.python.org/Flask-OAuth/, it writes that " Currently it only implements the consumer interface so you cannot expose your own API with OAuth." in the introduce . I think that means this extension may implements the provider interface in the future. Am I right? I find that there are some applications for django fo oauth like django-piston http://bitbucket.org/jespern/django-piston django-oauth http://code.welldev.org/django-oauth those both implement provider interface. Flask-OAuth have not implement provider interface yet, is that because Flask have not database 显示罗马拼音 integrated with database manipulating interface? I don't like django's auth, because I should add additional information to User and I don't like AUTH_PROFILE_MODULE solution. Frustrating, many django apps using User. Why not implement User as a interface not a class in django?
Hi, I can't comment on the rest due to lack of time this moment, but for one part I can give you an answer right away. On 8/18/10 9:13 PM, heww0205 wrote: > I don't like django's auth, because I should add additional information > to User and I don't like AUTH_PROFILE_MODULE solution. Frustrating, many > django apps using User. Why not implement User as a interface not a > class in django? That is the plan and it's ongoing: http://packages.python.org/Flask-Principal/ Regards, Armin
On 18 August 2010 20:22, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > I can't comment on the rest due to lack of time this moment, but for one > part I can give you an answer right away. > > On 8/18/10 9:13 PM, heww0205 wrote: >> I don't like django's auth, because I should add additional information >> to User and I don't like AUTH_PROFILE_MODULE solution. Frustrating, many >> django apps using User. Why not implement User as a interface not a >> class in django? > That is the plan and it's ongoing: > http://packages.python.org/Flask-Principal/ Any comments/suggestions/improvements would be most welcomed for this. We are using to integrate with our Single Sign On service of our ERP at work. Ali
What's the status of Flask-Principal re: becoming an approved extension ? On 19 August 2010 21:46, Ali Afshar <aafshar@gmail.com> wrote: > On 18 August 2010 20:22, Armin Ronacher <armin.ronacher@active-4.com> wrote: >> Hi, >> >> I can't comment on the rest due to lack of time this moment, but for one >> part I can give you an answer right away. >> >> On 8/18/10 9:13 PM, heww0205 wrote: >>> I don't like django's auth, because I should add additional information >>> to User and I don't like AUTH_PROFILE_MODULE solution. Frustrating, many >>> django apps using User. Why not implement User as a interface not a >>> class in django? >> That is the plan and it's ongoing: >> http://packages.python.org/Flask-Principal/ > > Any comments/suggestions/improvements would be most welcomed for this. > We are using to integrate with our Single Sign On service of our ERP > at work. > > Ali >
Hi,
On 8/19/10 10:49 PM, Dan Jacob wrote:
> What's the status of Flask-Principal re: becoming an approved extension ?
It looks fantastic and I would like to approve it, but because it will
be the central library for all kinds of Auth stuff, extra care is
needed. I absolute need to have other people review this as well and
play with it.
Regards,
Armin
On 19 August 2010 22:20, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > On 8/19/10 10:49 PM, Dan Jacob wrote: >> What's the status of Flask-Principal re: becoming an approved extension ? > It looks fantastic and I would like to approve it, but because it will > be the central library for all kinds of Auth stuff, extra care is > needed. I absolute need to have other people review this as well and > play with it. > I haven't applied for approval as such, because I really want to sit on it for a while. As Armin says, it could be the crux of authentication/authorisation with Flask, and I don't think this should be rushed. As it stands there are certainly some warts that need ironing out. Additionally, someone needs to implement integration with the current ouath etc stuff available, and also a reverse-ish test suite, where auth providers could run against to test their compatibility (again Armin's idea). Having said that, it's just about the first code I have ever written that Ronny has not been able to claim it sucks. Something about O(1), but really what more "approval" do you want than that!