Thanks Frank, will look into this set of openid providers. Pratik
On Wed, Mar 13, 2013 at 4:28 PM, Frank Bieniek < frank.bien...@produktlaunch.de> wrote: > Hi Pratik, > we have glued something together for openid. > > git+git://github.com/openid/python-openid.git@7d65da5987 > django-tastypie > django-guardian > hg+http://bitbucket.org/jezdez/django_openid_provider/@746ab34a974a > django-social-auth > oauth2 > # iptools/netaddress tools for the api access based on ip > netaddr > > Basically an openid server; we decide via the trusted roots of an openid > user which openid consumer is allowed to use the openid_provider for > authentication. > > And in the API Part, we use backend dedicated api users with a static ip > key combination. > You could use guardian for the access to resources. > > Hope that helps > > Thanks > Frank > > > > > Am 13.03.2013 11:02, schrieb Pratik Mandrekar: > > > Thanks for reminding about OAuth2. > > The API use case I'm currently dealing with includes authenticating my > own clients with my server, not third party apps. Hence Oauth2 seems a bit > weird here in terms of usability since it will ask user for permission to > access the backend service when they visit mydomain.com. It suits > Twitter/Facebook the way they use it but makes little sense for the app I'm > building. > > Also should OAuth2 do both authentication & authorization or should I > use OpenID. I am ideally looking for solutions that fit with default > authentication backends that come with Django. OAuth2 is probably a good > option I will consider, just not right now. > > Pratik > > On Wed, Mar 13, 2013 at 3:06 PM, Alec Taylor <alec.tayl...@gmail.com>wrote: > >> NO! - THERE IS RESTFUL METHOD OF AUTHENTICATION! >> >> Use OAuth2. >> >> RFC6749. There are a bunch of server implementations for Django. Use >> one of them. >> >> On Wed, Mar 13, 2013 at 8:06 PM, Pratik Mandrekar >> <pratikmandre...@gmail.com> wrote: >> > Thank you for the response! >> > >> > As Nick & Jani have pointed out, I figured out that there is no RESTFul >> way >> > for authentication. Neither is there one good way all clients could >> access >> > the api i.e Browsers can use Session Based Authentication while Mobile >> > clients are better of using API based/digest authentication and passing >> user >> > information. >> > >> > If authentication is handled separately, tastypie (and Django Rest >> > Framework) provide a very good RESTful api for doing most things. For >> APIs >> > consumed by web client, SessionAuthentication works great. If the same >> APIs >> > are to be used by non-web clients, the authentication can be extended to >> > include multiple ways of authenticating. This ensures that multiple >> clients >> > can use the same API with only different ways of authentication. >> > >> > My work is still in progress and I'll update as I get to complete the >> > project in the next few week. >> > >> > Thanks, >> > >> > Pratik >> > >> > >> > On Wed, Mar 13, 2013 at 12:17 AM, Nick Apostolakis <nicka...@oncrete.gr >> > >> > wrote: >> >> >> >> On 12/03/2013 01:06 μμ, Jani Tiainen wrote: >> >>> >> >>> >> >>> There is not exactly "RESTful way to authenticate", since after all >> REST >> >>> is just an architecture to represent different resources and thus it's >> >>> totally agnostic what comes to authentications and such. >> >>> >> >>> Simplest one (if you're use HTTP(S)) is to use basic/digest auth. >> Though >> >>> true REST is protocol agnostic (for example it could use unix sockets) >> >>> >> >>> Query authencation, a.k.a. API key, only one that you can do protocol >> >>> agnostic way. >> >>> >> >>> Cookie-based, for example posting credential query as POST (to create >> new >> >>> cookie) to /sessions/ url. Binds REST to HTTP(S) protocol again and >> DELETE >> >>> to /sessions/<session-id>/ to logout >> >>> >> >>> Personally, if working with Django and HTTP I would go for cookie >> based >> >>> auth since it would be natural. >> >>> >> >>> Otherwise API key isn't that bad option. >> >>> >> >> >> >> In my case I use Django and Tastypie. The whole thing works fine for >> non >> >> authenticated users and I would like to provide content for my >> registered >> >> users too. >> >> >> >> Would the best practice be to use Django login form to authenticate the >> >> user and then use Django authentication type (instead of api/key )with >> >> tastypie to access the content for registered users I am after? >> >> >> >> Thank you >> >> >> >> >> >> -- >> >> -------------------------------------------------------------- >> >> Nick Apostolakis >> >> e-mail: nicka...@oncrete.gr >> >> Web Site: http://nick.oncrete.gr >> >> -------------------------------------------------------------- >> >> >> >> -- >> >> You received this message because you are subscribed to a topic in the >> >> Google Groups "Django users" group. >> >> To unsubscribe from this topic, visit >> >> >> https://groups.google.com/d/topic/django-users/nexi3WtCICI/unsubscribe?hl=en >> . >> >> To unsubscribe from this group and all its topics, send an email to >> >> django-users+unsubscr...@googlegroups.com. >> >> >> >> To post to this group, send email to django-users@googlegroups.com. >> >> Visit this group at http://groups.google.com/group/django-users?hl=en. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> >> >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "Django users" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to django-users+unsubscr...@googlegroups.com. >> > To post to this group, send email to django-users@googlegroups.com. >> > Visit this group at http://groups.google.com/group/django-users?hl=en. >> > For more options, visit https://groups.google.com/groups/opt_out. >> > >> > >> > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-users/nexi3WtCICI/unsubscribe?hl=en > . > To unsubscribe from this group and all its topics, send an email to > django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
