logged in user permissions and roles caching

[Eddilbert Macharia]

Hello guys.... I'm a little bit confused... . When using django all that is, permissions and roles.... He is my understanding of how django works..... On each request made my by a client django creates a request object from it.... And by using the authentication middleware it adds the logged in user to this request object....now the unclear part....

Where does django get this authenticated user assuming the user is logged in, and the permissions that are cached on user object?

I didn't see where they were achieving this cause out of my head i would be using sessions to store logged in user?

I saw in the source code the permissions were being cached on the user object which also i would have stored in the session?

Enlighten me please.

[James Schneider]

Purely a guess, but to me, Django pulls fresh user information every request because the information regarding that user may have changed since the last request (changed permissions, etc.). Storing it in a session means that the information would need to be serialized and written back to your session backend at the end of the response (meaning extra process time), to sit there only until it is then overwritten on the next request or some other workflow causes the the session information to change (where the session has to be queried and deserialized, more processing time). Even worse, you now have two (or more) copies of that information in your database, and at least one of them in a non-indexed, linearly serialized, and comparatively bloated format. Doesn't bode well from a DB normalization standpoint. I make it a point to never statically store information that can be queried and/or computed from the raw data (in an optimized and indexed DB), unless those queries end up being significantly more expensive than storing the computed answer. To date, I haven't hit that point (to be fair, I don't work with large data sets that require extensive analysis, every case differs and should be profiled accordingly). 

If you instead used the user info from the session (which is likely possible using a custom auth backend), the user would not be subject to permission changes (or more importantly, if an account gets disabled) while the user has an active session until they log out and back in (where the user information in the session is presumably refreshed). I suppose you could develop a workflow to refresh the user information whenever permissions, etc. are modified, but that just adds complication for [what I see as] little gain.

Performing the lookup on every request is also compatible with Django applications that do not keep a session for each user.

Again, this is purely a guess, but the behavior makes sense to me. I suppose if you are trying to save one or two SELECT queries per page-load, it may be worth it, but it does add complexity and more work for the DB in addition to the extra processing required for serialization. I suppose personal preference for the described behavior also would play a role. 

If I'm incorrect here, someone please jump in. 

-James