Admin user history fix

[mlandauer]

On our current setup of Alevetli when an admin user makes a change and you look at it in the admin interface it doesn't correctly record the user that made the change.

I looked a little deeper and saw that there was a bunch of stuff going on where the admin user name was being passed around in the headers or something and apache rewrite rules had to be setup to handle this.

I found it all a bit confusing.

So, this patch does the simple thing and stores the admin user name in the session just like the user_id is stored in the session.

As far as I can tell this works

[mlandauer]

@crowbot I remember seeing somewhere that you use some kind of proxying at mySociety for your access to the admin interface. Is that right? Does that affect things for this pull request?

[crowbot]

Yes, we use http authentication via a proxied secure server to get the user
name for admin actions. I haven't looked at this request in detail yet, but
early next week I'll take some time to check whether we'll need a tweak to
this pull request to make it work for us.

On Thu, Oct 25, 2012 at 10:22 PM, Matthew Landauer <[email protected]

wrote:

@crowbot https://github.com/crowbot I remember seeing somewhere that
you use some kind of proxying at mySociety for your access to the admin
interface. Is that right? Does that affect things for this pull request?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/669#issuecomment-9794667.

[mlandauer]

Alternatively, we could get rid of the http authentication for the "super super user" by seeding the user table with an admin user. It would simplify the code quite a bit and make things potentially more consistent for the user.

[crowbot]

Sorry for the delay in getting to this. So currently, mySociety uses the skip_admin_auth flag and authenticates admin users via http auth over our secure proxy server.

I think in the long run, we should stop doing this, and let Alaveteli authenticate the admin users, but I'm a bit loath to change over quickly now, as super users can currently login with the same credentials in the front end as they use to access the admin interface, meaning those credentials could be intercepted when the user logs into the front end (ours is not run over https), and then used to access the admin interface. I think I'd prefer separate admin credentials, and a separate admin session (attached to the same account), or, in fact, to run the whole site over https.

So I suggest for now that we merge #683 instead. This should resolve your immediate issue, and give us some time to switch our whole site to https. I think the recommendation should probably be that all Alaveteli installs run entirely over https.

Tagging for reference #71 and #684

[mlandauer]

Thanks @crowbot! I've checked out #683 and it works for me. Now I understand how the SKIP_ADMIN_AUTH setting fits in with your proxy setup. I must admit when I first saw the SKIP_ADMIN_AUTH setting in the configuration my first thought was "why on earth would you want to make the admin interface open to world??" but it all makes perfect sense now :-)

+1 on merging #683 and closing this one

Also +1 on moving the whole Alaveteli install to https