On Mon, Aug 1, 2016 at 11:33 AM, Michal Petrucha <
[email protected]> 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 [email protected].
To post to this group, send email to [email protected].
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.
