Another option is to do all the authentication in Apache and use the Django RemoteUser backend. This would require writing an Apache authnz module to talk to the c++ server, and adjusting your Apache configs to require valid-user. Or, if not Apache, whatever server you are using.
Nothing about authentication would be handled at the Django level, but authorization would still be. https://docs.djangoproject.com/en/1.9/howto/auth-remote-user/ On Tue, Jun 7, 2016 at 4:27 PM, Michal Petrucha < michal.petru...@koniiiik.org> wrote: > 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, > > > > Daniel > > Hi 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. > -- 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/CAD4ANxWhJ8AmK4gg%3DWyyPfeVoZWWOHhAiGSoCL4fZkdnjw2hRQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
