<div dir="ltr"><div>Hello Petko,</div><div><br></div><div>I finally got this resolved. After turning on $EnableDiag, I started seeing these messages:</div><div><br></div><div>
<span class="gmail-mediumtext">Warning: Unknown: 
open(/var/cpanel/php/sessions/ea-php72/sess_vufc8hge4dhfmdcqm3d0d74ah3, 
O_RDWR) failed: No such file or directory (2) in Unknown on line 0<br>
<br>
Warning: Unknown: Failed to write session data (files). Please verify 
that the current setting of session.save_path is correct 
(/var/cpanel/php/sessions/ea-php72) in Unknown on line 0</span> <br></div><div><br></div><div>So, I opened a ticket with my hosting provider. According to them, the updated the php.ini to correct this. Looking at the output of phpinfo before and after, I see that they've changed the directory in session.save_path. I assume the old one either did not exist or had invalid permissions. No idea how it all managed to work for *years* then suddenly did not. Oh the joy of remote discount hosting!</div><div><br></div><div>I appreciate your help in getting to a resolution!</div><div>Thanks,</div><div>Jeff.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 22, 2023 at 3:07 PM Petko Yotov <<a href="mailto:5ko@5ko.fr">5ko@5ko.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If I understand correctly, users are able to sign into the protected <br>
section, with the correct password the page content is shown, but if you <br>
open a different protected page, the login form reappears, even if the <br>
same password is needed.<br>
<br>
I can think of 3 possible reasons for this:<br>
<br>
1. (least likely) Server (mis)configuration, the session data is not <br>
stored, or not available to PmWiki on subsequent page loads. This may <br>
happen if the PHP process has no read/write access to the session <br>
directory on the server, or that directory is full, or sometimes if the <br>
subsequent page requests are handled by different front-end servers that <br>
have different session directories.<br>
<br>
If this is the case, about the only thing that can be tried is to <br>
configure a different session directory like /home/user/.wikisessions <br>
outside of the document root, see:<br>
<br>
<br>
<a href="https://www.php.net/manual/en/session.configuration.php#ini.session.save-path" rel="noreferrer" target="_blank">https://www.php.net/manual/en/session.configuration.php#ini.session.save-path</a><br>
   <a href="https://www.php.net/manual/en/function.session-save-path.php" rel="noreferrer" target="_blank">https://www.php.net/manual/en/function.session-save-path.php</a><br>
<br>
Although on shared hosting providers sometimes this cannot be changed.<br>
<br>
<br>
2. Browser configuration, where the browser is configured to not store <br>
any cookies, or where a browser extension or a proxy prevents the <br>
cookies to be stored, or are quickly deleted, for this website only or <br>
for more websites. But you mentioned that there is a PHPSESSID session <br>
cookie in the browser so this is not very likely. Make sure you access <br>
the wiki with the same scheme, either http: or https:, not both.<br>
<br>
<br>
3. (most likely) Wiki misconfiguration, where either PmWiki outputs some <br>
characters or warnings before the headers are sent, and the browser <br>
ignores the cookie header, or some function caches the session data too <br>
early for some reason. Note that $DefaultPasswords entries should be <br>
added only to config.php, not to Group.php or Group.Page.php, and in <br>
general group passwords should be placed in a wiki page <br>
Group.GroupAttributes?action=attr. I assume this is the case.<br>
<br>
<br>
I'd reset the group passwords in GroupAttributes?action=attr -- just <br>
retype them in the attributes form, this should cause the hashes to be <br>
regenerated with the most recent algorithm.<br>
<br>
In a default PmWiki installation, the session identifier is modified <br>
after you sign in (unless you manually set <br>
$EnableAuthPostRegenerateSID). The value of the PHPSESSID cookie should <br>
be different before and after you signed in. If you see the same value, <br>
that means the browser didn't receive or didn't store the new session <br>
cookie.<br>
<br>
I'd disable redirects to check if there are any interstitial warnings <br>
($EnableRedirect = 0; in config.php).<br>
<br>
I'd enable diagnostics tools ($EnableDiag = 1;), and check the output of <br>
?action=diag, especially the $AuthList and $_SESSION variables, before <br>
and after signing in.<br>
<br>
I'd try with a "private window" (or "incognito window") and review the <br>
cookies before and after. Try with a different browser - if you normally <br>
use Firefox, I'd try with a recent Chromium-based browser, and vice <br>
versa.<br>
<br>
I'd check if there are any included PHP files with a closing "?>" marker <br>
followed by anything (even space or newlines). We recommend that the <br>
closing marker is omitted in local configuration, recipes or skin <br>
scripts, to prevent just that. Also, the starting "<?php" marker should <br>
be the very first thing in the scripts, not even spaces, newlines or BOM <br>
before it.<br>
<br>
I'd check if there are any included files that have been saved with a <br>
Byte Order Mark (BOM) -- these are 3 invisible bytes at the start of the <br>
file to identify the character encoding, but if these are sent before <br>
the cookies, the browser may not store the correct cookie. The BOM can <br>
be configured when you save a file, or in the File or Tools menu of your <br>
text editor, for example Kate/Kwrite have it as a checkbox in <br>
"Tools->Add Byte Order Mark (BOM)".<br>
<br>
If none of the above is helpful, I'd be happy to look at the wiki -- <br>
feel free to contact me privately.<br>
<br>
Petko<br>
<br>
<br>
On 22/09/2023 00:00, Jeff Henry wrote:<br>
> Thank you both for the replies.<br>
> <br>
> I've gone through the two suggestions from the troubleshooting page,<br>
> and have had no luck so far. According to the phpinfo page, sessions<br>
> are enabled, and do have a "reasonable" path specified. I didn't see<br>
> any of the functions mentioned in the second link in my config.php,<br>
> and I tried making a copy of my config.php with all of the included<br>
> recipes commented out, and still have the problem.<br>
> <br>
> If I open dev mode in Firefox, I can see the PHPSESSID and its value.<br>
> If I go to another page that requires the login, I see that the<br>
> session ID in the cooking remains the same. So it seems that the<br>
> session is being maintained?<br>
> <br>
> Not sure what else to look at now.<br>
> <br>
> Thanks,<br>
> <br>
> On Thu, Sep 21, 2023 at 4:01 AM Petko Yotov <<a href="mailto:5ko@5ko.fr" target="_blank">5ko@5ko.fr</a>> wrote:<br>
> <br>
>> I'd also check if there are any PHP errors or warnings near the top<br>
>> of the page, or in the html source. A PHP version update on the<br>
>> hosting may cause this before the headers are sent, which may<br>
>> prevent the browser from saving the session cookie.<br>
>> <br>
>> Petko<br>
>> <br>
>> On September 21, 2023 9:21:55 AM GMT+02:00, Simon<br>
>> <<a href="mailto:nzskiwi@gmail.com" target="_blank">nzskiwi@gmail.com</a>> wrote:<br>
>> <br>
>> There are a couple of answers on<br>
>> PmWiki | PmWiki / Troubleshooting [1]<br>
>> <br>
>> Including Why is PmWiki prompting me multiple times for a password<br>
>> I've already entered?<br>
>> and<br>
>> I have to log in twice<br>
>> <br>
>> [1]that may help<br>
>> <br>
>> Simon<br>
>> <br>
>> On Thu, 21 Sept 2023 at 08:26, Jeff Henry <<a href="mailto:jbhenry@gmail.com" target="_blank">jbhenry@gmail.com</a>> wrote:<br>
>> <br>
>> Hello,<br>
>> <br>
>> I have a site (running PmWiki 2.3.25) that has a Group that is<br>
>> protected with Group passwords for read and edit. In the past, a<br>
>> user has only had to enter the read password one time, to be able to<br>
>> see all pages within the group. But recently PmWiki is prompting for<br>
>> the password for each page in the group, even when going from one<br>
>> page to another within the same group. And this happens for both the<br>
>> Group password and the Admin password set in config.php<br>
>> $DefaultPasswords [2]. It is very annoying to our users to have to<br>
>> keep entering the password over and over again. I hadn't changed<br>
>> anything with the PmWiki software in quite a while. I did update to<br>
>> the latest stable to see if that would correct the problem, but it<br>
>> did not. Could my hosting provider have changed something in the PHP<br>
>> environment to cause this? Thanks,<br>
>> <br>
>> --<br>
>> Jeff Henry _______________________________________________<br>
>> pmwiki-users mailing list<br>
>> <a href="mailto:pmwiki-users@pmichaud.com" target="_blank">pmwiki-users@pmichaud.com</a><br>
>> <a href="http://www.pmichaud.com/mailman/listinfo/pmwiki-users" rel="noreferrer" target="_blank">http://www.pmichaud.com/mailman/listinfo/pmwiki-users</a><br>
> <br>
> --<br>
> Jeff Henry<br>
> <br>
> Links:<br>
> ------<br>
> [1] <a href="https://www.pmwiki.org/wiki/PmWiki/Troubleshooting" rel="noreferrer" target="_blank">https://www.pmwiki.org/wiki/PmWiki/Troubleshooting</a><br>
> [2] <br>
> <a href="https://www.pmwiki.org/wiki/PmWiki/SecurityVariables#DefaultPasswords" rel="noreferrer" target="_blank">https://www.pmwiki.org/wiki/PmWiki/SecurityVariables#DefaultPasswords</a><br>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Jeff Henry</div>