PasswordsAdmin-Talk

Why am I repeatedly prompted for passwords?

I have a site (running PmWiki 2.3.25) that has a Group that is protected with Group passwords for read and edit. In the past, a user has only had to enter the read password one time, to be able to see all pages within the group. But recently PmWiki is prompting for the password for each page in the group, even when going from one page to another within the same group. And this happens for both the Group password and the Admin password set in config.php $DefaultPasswords. It is very annoying to our users to have to keep entering the password over and over again. I hadn't changed anything with the PmWiki software in quite a while. I did update to the latest stable to see if that would correct the problem, but it did not. Could my hosting provider have changed something in the PHP environment to cause this? - Jeff: Sept 20, 2023.

The problem was with the session directory on the server, which was resolved after a raising support ticket with the hosting provider.

Shouldn't passwords-by-reference be inheritable at the site level?

Unlike for normal passwords such as @group authorizations, whenever I see in AuthList "Set by site" and a password-by-reference, the authorization is never granted to the user. My workaround is to actually specify "@_site_mypassword" at the group or page level - i.e. forsake site-level inheritance. This is unexpected behavior and confusing. If it's not a bug, it needs to be documented. -- RandyB September 24, 2016, at 07:49 PM

The @_site_ABCD way is actually a "hack", it was not designed to be used like this but we found out we could and we documented it. This may have been an error, as people find ways to use it, to rely on it and to have expectations we cannot necessarily satisfy. That being said, "@_site_read" and "@_site_edit" were indeed designed to be used inside Site.GroupAttributes and Site.SideBar, not as a group holding users - again, probably a sub-optimal syntax choice as it looks like a user group. --Petko October 05, 2016, at 12:11 AM

I do now rely on passwords-by-reference. It has made certain designs possible that otherwise would be unmanageable.

Perhaps the syntax choice was an error, but I think it may inadvertently turn out to be a great choice. It makes a lot of sense if you think of it as signifying indirection rather than as signifying a group. Seen as indirection, @mygroup means "go check the members of the group mygroup", and @_site_ABCD means "go check the site's definition of the ABCD password." The site's definition could be "@group", "password", "id:*", "@nopass", or anything else allowed by PmWiki.

For example, let's say I want to have a set of pages that are edit protected during one phase of a website's development, but open to editing in another. Right now I could set those pages' attributes to @_site_sometimesProtected and make the switch globally as needed via a line in the configuration file.

The beauty of thinking of @ as signifying indirection is that it allows us to make changes in the future that we don't even imagine now. Maybe PmWiki will someday have a new feature for passwords -- for example, support for a biometric reader that will confirm that you are not too drunk before you edit the page. :) To take advantage of the feature, I wouldn't have to change my pages -- I'd only have to change my configuration file.

I can accept that inheritance of @_site_level is only supported from the group to page level, not from the site to group level, but please don't ever take out the passwords-by-reference feature. And consider that what looks like an erroneous syntax choice may actually be a stroke of genius! -- RandyB October 05, 2016, at 10:53 AM

I absolutely understand you and appreciate the gravity. What I meant by "may have been an error" is "we documented it". :-) It is out of the question now to remove the feature, but unfortunately redesigning/upgrading it is unlikely. --Petko October 05, 2016, at 11:11 AM

I have tried to use the following (in pmwiki-2.2.0-beta52) and found that the attribute page method given works as expected, but that the $DefaultPasswords['source'] declaration was ignored and had no effect, ?action=source remained effective across the wiki. Des June 30, 2007, at 07:30 AM

You need to also add $HandleAuth['source'] ='source'; --Petko February 14, 2009, at 04:53 PM

Where can I change the Auth Form that ones is sent to when typing in MyGroup/MyPage?action=attr? This is not the same page as Site/AuthForm, but IS the page where a user would go to change their password...

This form is to change the passwords of the page, not those of the user. The title and the top text instructions are defined in a global variable $PageAttrFmt, and the form fields are printed by the function PrintAttrForm(). If only need to change the text instructions, you can define $PageAttrFmt in config.php, then yours will be used (and you could set it to "page:Site.AttrFormText" then simply edit that page in the wiki). If you want to use your own function to print the attr form, don't modify pmwiki.php, write your function in config.php and also there set:

  $HandleAttrFmt = array(&$PageStartFmt,&$PageAttrFmt,'function:MyPrintAttrForm',&$PageEndFmt);


This is a talk page for improving PmWiki.PasswordsAdmin.