On Mon, Aug 1, 2016 at 3:03 PM, James Schneider <[email protected]> wrote: > > > 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.
I understand and know all that. The situation is that they have an existing django app. Nothing in the app can be accessed without logging in. Then they have an in house developed non browser client app and they want to access some of the functionality from the django app in the other app. When the other app comes up they do have to logi in and I do use the django auth system for that. But when a request comes in from the app there is nothing to tie it back to the previously authorized session. Is there something from the initial auth I can use to get past the @login_required decorator on the views? -- 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/CACwCsY4rN4i_bruDHnt24BNJNGFLCCBRH-N2uvn4ap%3DOUCqx2A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
