Restful User Authentication for Ember/Backbone client with Tastypie

[Pratik Mandrekar]

Hello,

I'm trying to figure out what would be the best way to integrate django with ember.js/backbone from the user authentication point of view. I'm using Tastypie for creating RESTful resources.

I have no problem creating APIs once a user has been authenticated using the Session based authentication but I am wondering what is the best RESTful way to create  a user authentication API that can confirm to Session based authentication.

Also if I'm not mistaken the right way to authenticate the client is via the API key authentication right?

Thanks,

Pratik

[Nick Apostolakis]

> --
>
Tthis is cool, I was about to ask the same thing. I believe that this
thread will be interesting.


--
--------------------------------------------------------------
Nick Apostolakis
e-mail: nick...@oncrete.gr
Web Site: http://nick.oncrete.gr
--------------------------------------------------------------

[Jaimin Patel]

Not sure about your first questions.

For right way to authenticate is solely depends on your requirement. 

If you don't care about who is using the data > you can turn off the data, 

if you want only your application users to use it > you can use DjangoAuthentication

if you want minimal security > use Dajngo API key Authentication

More secure > use OAuth mechanism

hope it helps!

[Alec Taylor]

You'll want to setup an OAuth2 server for this.

--
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...@googlegroups.com.
To post to this group, send email to django...@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.
 
 

[Jani Tiainen]

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.

--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

[Nick Apostolakis]

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

[Pratik Mandrekar]

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  

--
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+unsubscribe@googlegroups.com.

[Alec Taylor]

NO! - THERE IS RESTFUL METHOD OF AUTHENTICATION!

Use OAuth2.

RFC6749. There are a bunch of server implementations for Django. Use
one of them.

>> django-users...@googlegroups.com.

>>
>> To post to this group, send email to django...@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...@googlegroups.com.

[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

[Frank Bieniek]

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

>> οΏ½--------------------------------------------------------------
>> οΏ½ οΏ½ οΏ½ οΏ½ οΏ½ οΏ½ οΏ½ οΏ½ οΏ½ οΏ½Nick Apostolakis
>> οΏ½ οΏ½ οΏ½ οΏ½ οΏ½ οΏ½ οΏ½ e-mail: nick...@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...@googlegroups.com.
>>
>> To post to this group, send email to django...@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...@googlegroups.com.
> To post to this group, send email to django...@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...@googlegroups.com.
To post to this group, send email to django...@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.

οΏ½
οΏ½

[Pratik Mandrekar]

Thanks Frank, will look into this set of openid providers.

Pratik

On Wed, Mar 13, 2013 at 4:28 PM, Frank Bieniek <frank....@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

>>  --------------------------------------------------------------
>>                    Nick Apostolakis
>>               e-mail: nick...@oncrete.gr
>>          Web Site: http://nick.oncrete.gr