How do I get the session cookie from the login and then how do I pass it in the subsequent request?
On Monday, August 1, 2016, ludovic coues <[email protected]> wrote: > 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] > <javascript:;>>: > > On Mon, Aug 1, 2016 at 3:03 PM, James Schneider <[email protected] > <javascript:;>> > > wrote: > >> > >> > >> On Mon, Aug 1, 2016 at 11:33 AM, Michal Petrucha > >> <[email protected] <javascript:;>> 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] <javascript:;>. > > To post to this group, send email to [email protected] > <javascript:;>. > > 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] <javascript:;>. > To post to this group, send email to [email protected] > <javascript:;>. > 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. > -- 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/CACwCsY6%3Dk%3D7Kaw5pfys68ez_iv4ZJQvh_7PhJWPiC%3DQos4DFkA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
