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)