[pmwiki-users] Working solution for CMS style interface with IMS caching

[Henrik Bechmann]

Patrick,

I have implemented a working solution for differentiation of page layout 
based on native PmWiki password protection state, in the presence of IMS 
caching, as follows:

In my farmconfig.php I have:

$HandleActions['logout'] = 'CacheLogoutHandler';
function CacheLogoutHandler($pagename, $auth = 'read') {
 global $EnableIMSCaching;
 $EnableIMSCaching = 0;
 HandleLogoutA($pagename, $auth); # call the legit handler
}

(Thanks to Dominique for this) This code allows refresh after logout in 
the presence of $EnableIMSCaching=1. (I have caching turned on so that 
page position is preserved for users who go back to a page after 
clicking through -- many of our pages are quite long).

Later in farmconfig.php I have:

include_once('local/config.php');
$pagename = ResolvePageName($pagename);
$isEditAuthorized = (boolean)RetrieveAuthPage($pagename, 'edit', false, 
READPAGE_CURRENT);

Thanks to you for this. It sets the $isEditAuthorized variable so that I 
can use it elsewhere to make page layout decisions. The include_once is 
required so as to allow for initialization required by the native 
Resolve... and Retrieve... functions.

Then later again in farmconfig.php (for example) I make custodian (ie. 
'author') layout decisions:

function GetCustodianMenu() {
 global $isEditAuthorized;
 if (!$isEditAuthorized) {
  print "<li><a href='$PageUrl?action=login'>Login</a></li>";
 } else {
  print "<li><a id='currentpagelink' href='$PageUrl'>View page</a></li>
<li><a href='$PageUrl?action=edit'>Edit Page</a></li>
<li><a href='$PageUrl?action=diff'>Page History</a></li>
<li><a href='$PageUrl-Sidebar?action=edit'>Edit Page Sidebar</a></li>
<li><a href='$ScriptUrl/$Group/Sidebar?action=edit'>Edit Group 
Sidebar</a></li>
<li><a 
href='$ScriptUrl/$DefaultGroup/DepartmentSidebar?action=edit'>Edit 
Department Sidebar</a></li>
<li><a href='$ScriptUrl/$DefaultGroup.SectionList?action=edit'>Edit 
Folders Menu</a></li>
<li><a href='$ScriptUrl/$Group/ArticleList?action=edit'>Edit Documents 
Menu</a></li>
<li><a href='$ScriptUrl/LibraryOfStories.FrontPage'>Library Of 
Stories</a></li>
<li><a target='_blank' href='/gallery/index.php'>Photo Gallery</a></li>
<li><a target='_blank' 
href='/common/wiki/pmwiki.php?n=DufferinParkWiki.FrontPage'>Custodian 
Help</a></li>
<li><a href='$PageUrl?action=logout'>Logout</a></li>";
 }
}

...which is called from the page template as 
<!--function:GetCustodianMenu--> in the appropriate sidebar location.

All of this works as expected in Internet Explorer. The Firefox cache is 
not as responsive however, and requires special procedures. Also, it 
turns out that PmWiki deletes the Author Name cookie with the logout 
operation (which I do not think is desirable in most situations).

To deal with the Firefox cache, and PmWiki cookie issue, I have 
customized Site.AuthForm (and added it to shared.d) by adding the 
following two notices for my authors:

---------------------

Page refresh required after login/logout

If you are using Firefox, you will have to refresh the web page after 
login or logout in order to see the page layout associated with the 
current authorization. To do this, hold down the shift key and click on 
the refresh icon on the browser's toolbar.

Author Name removed from cookie with logout

For either Firefox or Internet Explorer, after logout the Author: Name 
that is required to save an edit is removed by PmWiki from your cookie, 
so you will have to re-enter it the next time you want to save an edit. 
To avoid this, do not use logout.

-----------------------

Therefore my authors are routinely reminded of procedures to follow to 
deal with these issues (they use FF, and normally do not need to logout 
as such).

Note that Ctrl+R does NOT work in Firefox. Apparently <Shift> + the 
refresh icon does a deeper refresh.

So it's not the prettiest thing in the world, but it's acceptable, at 
least for a while.

My suggestions:

1. Hunt down the tweak required to get FF to refresh (if available).

2. IMHO the Author Name (as opposed to ID) should never be removed from 
the cookie. It is not a security feature, but rather a convenience for 
the author, such that he/she doesn't have to keep adding his/her name 
from the same computer all the time (when $EnablePostAuthorRequired = 
1). Perhaps a $EnablePersistAuthorCookieValues variable or some such 
could give people a choice, if that is an issue.

Thanks again to all (particularly Pm, Dominique, and Hagan) for your 
help and patience on this one.

All the best,

- Henrik


-- 

Henrik Bechmann
www.osscommons.ca
www.bechmannsoftware.com
Webmaster, www.dufferinpark.ca