It would also be a good idea to check against 1.17.0, 1.18br and
1.19trunk and see if this issue has been fixed somewhere down the
pipeline.
On Mon, Oct 31, 2011 at 3:30 PM, Dan Nessett <dnessett(a)yahoo.com> wrote:
On Sat, 29 Oct 2011 16:10:51 -0400, Frederick Grose
wrote:
On Sat, Oct 29, 2011 at 2:58 PM, Dan Nessett
<dnessett(a)yahoo.com> wrote:
On Fri, 28 Oct 2011 23:30:10 +0200, Platonides
wrote:
Dan Nessett wrote:
> After testing, it appears moving to 1.16.5 solves the problem.
> Should I file a bug against 1.16.2 and mention it is fixed in
> 1.16.5? This might help those who run 1.16.x, x < 5 if, if they run
> into the same problem
Such bug wouldn't get any action. Bugs in 1.16.x are fixed in a new
release 1.16.y (y > x). This is already fixed, Nothing we can do to
solve people in old versions.
I think you have missed the point. The bug is already fixed in 1.16.5
(and I presume in later releases). However, many wikis don't upgrade
regularly. If their situation is like ours, there is a very small tech
staff and it is unrealistic to upgrade often (we ran 1.13.2 for 3 years
before upgrading to 1.16.2). In addition, in our case we modify the
standard distribution with a patchkit, so deploying a new release of MW
requires applying that kit and testing before going live with it. This
is not a trivial amount of work.
Consequently, I would guess there are many wikis running 1.16.x, x < 5.
If they run up against the bug described in this thread and search
Bugzilla for a fix, they won't find it. If I file a bug describing the
problem and indicate it is fixed in 1.16.5, it provides those sites
with knowledge about the problem without posting a question here or
elsewhere.
--
-- Dan Nessett
This thread has been educational on both the topic and patching
conventions.
A well worded bug report, as you suggest, with a link back to this
thread, would be a benefit without risk.
Please also provide this thread with a link to that bug report.
Thanks! --Fred
It appears I spoke too soon. The results I am getting from MW 1.16.5 are
inconsistent. I invite someone else to try the following on a development
installation of MW 1.16.5 and see if they get the results I do.
On a development machine (NOT a production machine):
+ Log out of the wiki, if you are currently logged in (or have checked
the "remember me" box).
+ Make the following changes to php.ini:
- session.gc_probability = 100
- session.gc_divisor = 100
- session.gc_maxlifetime = 60
- session.save_path = <some directory writable by httpd>
+ Restart httpd
+ Delete all sessions in the session directory (i.e., session.save_path).
This isn't strictly necessary, but it makes it easier to see how the
session data are manipulated.
+ Access the wiki and login (DO NOT CHECK THE "REMEMBER ME" BOX). Move to
a wiki page that you can edit. A new session file is created and it will
look something like (assuming you logged on as the WikiSysop user):
wsUserID|i:1;wsToken|s:32:"0ff5b9ecf52077fb05cc74731f13ba2b";wsUserName|
s:9:"WikiSysop";wsLoginToken|N;
+ Wait 60 seconds or more.
Edit the page by clicking on the edit tab. Make a change and save the
page. You will see the message "Sorry! We could not process your edit due
to a loss of session data. Please try again. If it still does not work,
try logging out and logging back in." The session file will contain:
wsUserID|i:1;wsUserName|s:9:"WikiSysop";
Save the page again. This time it will work. The session data will not
change. Now look at Recent Changes. The edit will show the successful
edit assigned to an IP address not to the user.
If this result is reproducible, it indicates three problems. First, an
edit is allowed even though the session has expired. Second, the edit is
assigned to an IP address (which, actually, is a direct result of the
first problem). Finally, I can continue to edit pages even though I am
shown as logged out (the "log in/create account" message is shown at the
top of the page).
This is exactly the same behavior for MW 1.16.2. Previously, I tried a
different procedure on both MW 1.16.2 and MW 1.16.5 and MW 1.16.5
appeared to handle the problem correctly. However, it seems both releases
behave the same when executing the procedure given above.
--
-- Dan Nessett
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l