The session cookie ? Or you could use another decorator or a middle-ware doing authentication based on the ip and some information passed as get argument. Like a token returned by django when you auth the user.
The request hit the new decorator, the decorator notice the user isn't logged in and that it provide a token. It check if the token match a recently logged in user and its ip and maybe the user-agent. If that's the case, log the user in and let the request hit the @login_required decorator. If you don't simply reuse the session cookie, I would spend some time, listening with wireshark and messing with a browser, checking that I am not opening a hole. 2016-08-01 21:39 GMT+02:00 Larry Martell <[email protected]>: > 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. -- Cordialement, Coues Ludovic +336 148 743 42 -- 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/CAEuG%2BTbEtZ17sYPWM2683aLC5%3DVV%2BVxCGvCbTr-F0gFV-32N-g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
