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
You need to also add
Where can I change the Auth Form that ones is sent to when typing in
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);