On Tue, Jun 07, 2016 at 01:44:29PM -0700, Daniel Wilcox wrote:
> Two options:
>
> 1. Tie into Django Authentication
>
> You can make a custom authentication backend and do whatever you want for
> authentication -- including talk over a named pipe and get the OK for users
> if you like.
>
> With that you'll be able to use the login_required decorator. To make a
> authentication backend you will also need some kind of User object to pass
> to the built-in login and logout functions -- which take care of marking
> the session appropriately.
>
> Of course that bring up a couple other things like storing your session
> data -- I presume it is happening currently a cached session then? Or is
> there a solution for getting sessions data elsewhere? Anyway typically
> only the session-id is stored in the cookie and the value is a pickled
> dictionary if you need to dig into that.
>
> 2. c++ is handling users, and auth... and maybe sessions
>
> It sounds like this may be your situation. In which case the appropriate
> thing to do is to decorate your view functions to check if the requesting
> session is logged in, and either redirect to login or call the view
> function decorated. You could use memcache or something like that to store
> login creds somewhere django can read them directly -- otherwise you'll
> probably be calling out to your named pipe on every request to one of these
> views.
>
> From what I'm reading you'd want something like this -- where you fill in a
> function to call out to your named pipe in 'named_pipe_auth_ok'.
>
> def my_required_login(view_func):
> def return_func(*args, **kwargs):
> assert args[0]
> request = args[0]
> session_id = request.session.session_id
> if named_pipe_auth_ok(session_id):
> return view_func(*args, **kwargs)
> else:
> return redirect('/some/login/url')
> return return_func
>
> Sounds like fun, cheers,
>
> DanielHi Prabhat, Daniel's advice looks correct, but I wanted to add that it would most likely be a good idea to implement a custom authentication backend [1], and use as much of django.contrib.auth for the rest as possible. There are so many little details that you would have to take care of should you decide to implement everything on your own – session invalidation on login/logout, correct handling of login redirects, and whatnot. In the best case scenario, you'd end up reimplementing a big chunk of django.contrib.auth, only with your custom code, which will inevitably be less thoroughly tested; in the worst case, you'd be left with gaping security holes that are easy to exploit. The possibility of plugging custom authentication backends into django.contrib.auth exists for use cases just like yours. It's the smart thing to do. Good luck, Michal [1]: https://docs.djangoproject.com/en/1.9/topics/auth/customizing/#writing-an-authentication-backend -- 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+unsubscr...@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/20160607212741.GY29054%40koniiiik.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
