Jamie Bliss wrote:
This has been observed by others, and it is believed that those cases were linked with poor/bad sessions.
During my exploration of the code (the EditPage object), I was unable to determine the cause of this.
Well, the cause is usually an incorrect session.save_path setting in php.ini. This is particularly often on Windows, because for some reason the Unix default of /tmp gets left there on the Windows distribution.
If you mean the cause for edits to fail when sessions are broken, it's like this:
When you perform various operations while logged in, such as editing, the edit form is sent along with a hidden field containing a randomly-generated token value. This token is stored in the session data on the server, and when you submit the form the stored edit token is compared against the submitted edit token value. If the tokens don't match, the submission is rejected.
This is a security measure, protection against client-side attacks such as submission of a form from another site. If you visit a malicious web site in your browser while logged in to the wiki, then that site could submit arbitrary form data to the wiki and your cookie & session data would go along with it. The malicious site however would not be able to gain access to the edit token value, so would be unable to include it with the submission; thus the edit token proves that not only is your browser logged in, but the form submission actually came from the same session. (Other possiiblities for trying to validate this could include referer checks, but this is less reliable. Among other problems, some people use proxy servers which strip referer headers.)
Without this check, there's potential that administrative actions or modifications to site-wide JavaScript could be make through an attack by getting a logged-in administrator to visit some web site.
-- brion vibber (brion @ pobox.com)