Description
One user may get the version of the page of the user who refreshed the cache before him.
Example
Go to this wiki: http://nirs.dyndns.org/main/UserPreferences
- Login as UserA with password of UserA
- Open another browser, and login as UserB
As UserA, click on a page and refresh the cache
In the other browser, as UserB, go to the same page
- You get UserA version! - look at the user name at the top
This completly break any ACL as you can read pages you should not read.
This work in the same way with non login user. You get the last logined user version.
Details
MoinMoin Version |
1.3--patch-154 |
Workaround
Discussion
I cannot verify this on MoinMaster. And I cannot see the connection to ACLs. I would guess that the caching of the UI stuff is broken. I cannot verify this on the given wiki either. May be you did not use two different browsers or browsers that share common cookies? Please test again with two really different browsers (or even different maschines). -- FlorianFesti 2004-10-02 14:23:57
I tested with two browsers on same machine - Safari and Mozila. they do not share cookies as far as I know. MoinMaster does not alwyas run on the latest code, as twisted must be restarted for this. The example wiki run on cgi with the current code from tla. -- Nir
I just update now to patch 157 at HOME and I can't reproduce it.
I think the problem is the proxy. I found this problem using a machine that connected to the web through a proxy. -- Nir
I could reproduce the problem again from Home by accesing the wiki not locally but through my dyndns address. Probably my ISP use a transparent proxy. I got a page as the user: AlexanderSchremmer - its not a page I viewed on another browser on my mahine, its a page Alexander viewed on his machine, and the proxy sent me his cached version of page! -- Nir
This does not look like a problem related to the proxy because the proxy cannot know my credentials. Thus it is a bug in moinmoin, a major one. -- AlexanderSchremmer 2004-10-07 14:33:29
Or a bug in Twisted ... -- AlexanderSchremmer 2004-10-07 18:37:27
This was a bug in an internal version developed on nirs pc. He had a broken cookie on his machine. We cant reproduce it on a normal install. -- AlexanderSchremmer 2004-10-07 21:37:22
If its the proxy, then the proxy wasnt aware of the cacheability. In order to let it know, we need some headers (cf. http://www.ircache.net/cgi-bin/cacheability.py). These headers should be generated based on the WSAP status of the page (no idea if something like that exists). So we might add headers which invalidate the document directly if the page contains macros etc. Otherwise we could sent the Last-modified time of the caching system of moinmoin. Cache-Control-headers are useful here as well. -- AlexanderSchremmer
About cache control: http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc2109.html#sec-4.2.3
Cookies are now never cached (main--1.3--patch-179), and I could not reproduced the problem with 2 browsers while accessing the wiki through my ISP transpatent proxy.
I will try later at the same setup I discovered the problem at the first time.
Checked again at the first location the problem was discovered. Seems that the proxy there is broken, I logout, click on FindPage, I get FindPage as UserA. I login, go to another page and I am not logined! -- NirSoffer 2004-11-27 13:59:15
Plan
- Priority: High - critical security bug!
- Assigned to:
- Status: closed
- cookies are safe from caching problems now, could not reproduce the bug until now.