00329: Lost edit page content when set both "read" and "edit" password using sessionauth.php

Summary: Lost edit page content when set both "read" and "edit" password using sessionauth.php
Created: 2005-02-11 20:31
Status: Closed - not a bug
Category: Bug
Assigned:
Priority: 2
Version: 1.0.5
OS: all

Description: Sometimes we set both "read" and "edit" password on a page, and the two password may be different. When we want to edit this page, sessionauth.php will ask the "edit" password. We input the password and submit the new edit content. If "read" and "edit" password is different, then the sessionauth.php must ask for "read" password. Because submiting a new edit content is use the "post" method, then the sessionauth.php's asking for "read" password catch the "post" parameters, but not re-post them after the check for "read" password. Then the new edit content is lost, it haven't been saved.

A way to solve this is: let sessionauth.php catch and cache all post parameters, and re-post them between the form of sessionauth.php.


Sorry, I test this on my localhost again, and it doesn't really the case, the sessionauth.php works well. So it is not a bug.

What make me trouble is when I use both sessionauth.php and blockedit.php at the same time, they seem conflict and I didn't found the way to solve it. When I am trying, I found this fake bug.


Ummm... what's blockedit.php? --Pm


blockedit.php is a cookbook-v1 solution to ban ip, which could be useful to get rid of vandalism, the page about it is Cookbook-V1.RestrictingEdits.

Now I search the wiki again and found the Blocklist cookbook script, and I realized it is a good replacement of blockedit.php. I tried it and find it perfect on pmwiki 1.0.5. Thus I got the solution.

Thanks for response. --Elias Soong