2

I am running a Django through mod_python on Apache on a linux box. I have a custom authentication backend, and middleware that requires authentication for all pages, except static content.

My problem is that after I log in, I will still randomly get the log in screen now and again. It seems to me that each apache process has it's own python process, which in turn has it's own internals. So as long as I get served by the same process I logged in to, everything is fine and dandy. But if my request gets served by a different apache process, I am no longer authenticated.

I have checked the HTTP headers I send with FireBug, and they are the same each time, ie. same cookie.

Is this a known issue and are there workarounds/fixes?

Edit: I have a page that displays a lot of generated images. Some off these will not display. This is because they are too behind the authenticating middleware, so they will randomly put up a login image. However, refreshing this page enough times, and it will eventually work, meaning all processes recognize my session.

Staale
  • 27,254
  • 23
  • 66
  • 85
  • After running for a while, things seem more stable. However I don't enjoy how unstable this is. Maybe I need to reset apache a few times and let it run for some minutes before things work consistently. – Staale Oct 03 '08 at 11:39

5 Answers5

2

You are correct about how Apache handles the processes, and sometimes you'll get served by a different process. You can see this when you make a change to your site; new processes will pick up the change, but old processes will give you the old site. To get consistency, you have to restart Apache.

Assuming a restart doesn't fix the problem, I would guess it's something in the "custom authentication backend" storing part of the authentication in memory (which won't work very well for a web server). I would try setting MaxRequestsPerChild to 1 in your Apache config and seeing if you still get the login screen. If you do, something is being stored in memory, maybe a model not being saved?

Hope that helps!

P.S. Just out of curiosity, why are you using a custom authentication backend and a middleware to ensure the user is logged in? It seems Django's contrib.auth and @login_required would be easier...

tghw
  • 25,208
  • 13
  • 70
  • 96
  • I need to authenticate against active directory, hence my own authentication backend. Nothing is stored in memory. I am not using @login_required because this is for an intranet available externally, and I don't trust myself to remember to put that on all views – Staale Oct 03 '08 at 12:23
  • What does setting MaxRequestsPerChild to 1 do? – tghw Oct 03 '08 at 15:54
  • Sorry, didn't get to test that, and now I won't be able to until monday. Thanks for the advice at least, I will try it out. – Staale Oct 03 '08 at 19:04
0

How to ensure that session is not cleared after Apache restart( or stop and start) ?

Because when I upgrade my source code and restart Apache, I refresh the web page and there I have to login again. Session is lost.

Session is stored in Memcache. No idea how and why its cleared. How to preserve the session so that the user need not login after the apache restart?

Geetanjali
  • 101
  • 1
  • 1
  • 5
0

Do you have standard database-driven sessions? Is caching enabled in settings?

ilvar
  • 5,718
  • 1
  • 20
  • 17
0

I highly recommend you don't set MaxRequestsPerChild to 1, as that would cause so much overhead as each process gets killed off and respawns with every request.

Are you using apaches preform MPM or worker MPM?

Take a look at http://docs.djangoproject.com/en/dev/howto/deployment/modpython/?from=olddocs that may give you some help

jlintz
  • 463
  • 3
  • 8
0

If you are using some global variables to hold data of your custom authentication session, you need to change this to use either file, database or memcached. As stated above mod_python launches few processes and there's no shared memory between them.

I recommend using memcached for this, also use cookies to store session ID or pass it with as GET parameter so that later you can easily extract session data from the cache.

Bartosz Ptaszynski
  • 726
  • 7
  • 8