Re: selectively requiring login

On Mon, Aug 1, 2016 at 11:33 AM, Michal Petrucha <michal.petrucha@koniiiik.org> wrote:

On Mon, Aug 01, 2016 at 12:17:38PM -0400, Larry Martell wrote:
> I have a view that is accessed both from the browser and from a
> non-browser app. The request from the non browser app come from a
> remote app where the user has already had to login (or they would
> never get to the point where they could cause the request to be sent).
> Is there a way to make login required when the request comes from a
> browser but then not have login required when the request comes from
> the app?

That sounds like a bad idea. Even with the "app", when a request is

+100

 

being made, the user has to be authenticated somehow. If you allow
your "app" to access the view without authentication (regardless of
what criterion you pick to determine it is the "app", be it the
user-agent, referrer, or whatnot), what's to prevent a motivated
attacker from finding the criterion out using a sniffing proxy or some
other tool, and just making the request directly?

+100

Your end-users (regular browser sessions) and apps using API calls should probably be using a separate URL structure. In most cases the API calls have a unique identifier in the path such as being prepended with '/api/' and are often followed by a version number ('/api/v1/') to maintain compatibility with concurrent API versions.

While it is a terrible idea to have an authenticated and non-authenticated URL for the same resource (or set of resources), you can easily achieve this by having separate URL's for your browser sessions vs. API calls, and performing the login decoration on the browser URL in the urls.py file rather than decorating the view directly. The URL for the API call would not be decorated and can be accessed without requiring a login, but both URL's would point at the same view.

My advice is not to do that, though. 

You should heavily consider either having your app be authenticated (login and grab a session token via your API), or provide an API token to the local app that is associated with the user you want. The latter will require some extra infrastructure. 

The alternative is to not have the user log in no matter how they are accessing the URL. If it works without logging in, and there are no resources to protect, that sounds like the way to go. With the implementation you've indicated, you'll be asking for trouble operationally later when your view is expecting a user object, but it doesn't get one. Means more complexity for no appreciable gain. 

You can also implement some sort of SSO implementation (Shibboleth, CAS, OAuth, etc.) that can be used by both regular browser sessions and your custom application.

-James

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVL%2B5G9RfNXvzYyZ9f7Wa%2Be1XYeop1V3ZENwOj4yUn64w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.