Description

As a superuser, changing the preferences for another user leads to replacement of superuser-preferences instead of preferences for the other user.

Steps to reproduce

1. Login in as the Superuser

2. Go to UserPreferences

3. Select a different User in the SelectUser dropdown menu

4. Change a preference for that other user (tested this by changing the e-mail address)
5. Save

Result: The preferences of the Superuser get overwritten with the settings of the (presumably) edited user. The preferences for the selected User remain unchanged. All preferences get replaced, not just the one changed.

Example

Details

wikiconfig.py has {{{auth=[http] user_autocreate = 1}}}

Workaround

Do not try to save preferences for a different user.

Discussion

It is rather unpleasant to loose, eg., the subscribed-to pages setting.

This is caused by this code relying on working cookie auth:

                self.request.user = theuser
                self.request.setCookie()
                return  _("Use UserPreferences to change settings of the selected user account")

If you allow http auth only, we can't convince apache that you are another user now.

Are there any other possibilities to get this to work now? Like adding "cookie" as another authentication method?

Try auth = [moin_cookie, http].

• This seems to work, but it is rather strange: I'm the other user after saving the preferences. When I log out afterwards, I am immediately re-authenticated using http authentication. It does not "feel" right. Shouldn't there be a way to not save preferences for somebody else without first becoming that somebody? Unfortunatly, python is one of the languages I'm not fluent in, so I cannot help out in this area. Well, the current implementation is kind of a "su - otheruser". This enables you to save prefs and even do / check other stuff as that otheruser. So an admin can check if some user reports trouble that admin can not reproduce using his own account. I added a note to CHANGES that moin_cookie is required for this function.

Re-opening, since it was marked MoinMoinNoBug without any explanation. (Yes, I did see a mention of moin_cookie being documented now in the change comment, but should a preson have to look there to see the reason?) Also, a link to that documentation and maybe a hint on how that resolves the problem would be nice. -- SteveDavison 2007-10-11 01:42:19

Well, moin has no control about http auth, this is done by the server and the server sets some env vars moin uses. Moin has no means to change the user when http auth is the only auth method. But for being able to switch users, moin needs that control, so it can only do it for the auth thing it itself controls, and this is cookie based auth. -- ThomasWaldmann 2007-10-11 06:43:41

Plan

• Priority:
• Assigned to:
• Status:

CategoryMoinMoinNoBug