Re: Repeated prompts for passwords?

If I understand correctly, users are able to sign into the protected 
section, with the correct password the page content is shown, but if you 
open a different protected page, the login form reappears, even if the 
same password is needed.

I can think of 3 possible reasons for this:

1. (least likely) Server (mis)configuration, the session data is not 
stored, or not available to PmWiki on subsequent page loads. This may 
happen if the PHP process has no read/write access to the session 
directory on the server, or that directory is full, or sometimes if the 
subsequent page requests are handled by different front-end servers that 
have different session directories.

If this is the case, about the only thing that can be tried is to 
configure a different session directory like /home/user/.wikisessions 
outside of the document root, see:

   
https://www.php.net/manual/en/session.configuration.php#ini.session.save-path
   https://www.php.net/manual/en/function.session-save-path.php

Although on shared hosting providers sometimes this cannot be changed.


2. Browser configuration, where the browser is configured to not store 
any cookies, or where a browser extension or a proxy prevents the 
cookies to be stored, or are quickly deleted, for this website only or 
for more websites. But you mentioned that there is a PHPSESSID session 
cookie in the browser so this is not very likely. Make sure you access 
the wiki with the same scheme, either http: or https:, not both.


3. (most likely) Wiki misconfiguration, where either PmWiki outputs some 
characters or warnings before the headers are sent, and the browser 
ignores the cookie header, or some function caches the session data too 
early for some reason. Note that $DefaultPasswords entries should be 
added only to config.php, not to Group.php or Group.Page.php, and in 
general group passwords should be placed in a wiki page 
Group.GroupAttributes?action=attr. I assume this is the case.


I'd reset the group passwords in GroupAttributes?action=attr -- just 
retype them in the attributes form, this should cause the hashes to be 
regenerated with the most recent algorithm.

In a default PmWiki installation, the session identifier is modified 
after you sign in (unless you manually set 
$EnableAuthPostRegenerateSID). The value of the PHPSESSID cookie should 
be different before and after you signed in. If you see the same value, 
that means the browser didn't receive or didn't store the new session 
cookie.

I'd disable redirects to check if there are any interstitial warnings 
($EnableRedirect = 0; in config.php).

I'd enable diagnostics tools ($EnableDiag = 1;), and check the output of 
?action=diag, especially the $AuthList and $_SESSION variables, before 
and after signing in.

I'd try with a "private window" (or "incognito window") and review the 
cookies before and after. Try with a different browser - if you normally 
use Firefox, I'd try with a recent Chromium-based browser, and vice 
versa.

I'd check if there are any included PHP files with a closing "?>" marker 
followed by anything (even space or newlines). We recommend that the 
closing marker is omitted in local configuration, recipes or skin 
scripts, to prevent just that. Also, the starting "<?php" marker should 
be the very first thing in the scripts, not even spaces, newlines or BOM 
before it.

I'd check if there are any included files that have been saved with a 
Byte Order Mark (BOM) -- these are 3 invisible bytes at the start of the 
file to identify the character encoding, but if these are sent before 
the cookies, the browser may not store the correct cookie. The BOM can 
be configured when you save a file, or in the File or Tools menu of your 
text editor, for example Kate/Kwrite have it as a checkbox in 
"Tools->Add Byte Order Mark (BOM)".

If none of the above is helpful, I'd be happy to look at the wiki -- 
feel free to contact me privately.

Petko


On 22/09/2023 00:00, Jeff Henry wrote:
> Thank you both for the replies.
> 
> I've gone through the two suggestions from the troubleshooting page,
> and have had no luck so far. According to the phpinfo page, sessions
> are enabled, and do have a "reasonable" path specified. I didn't see
> any of the functions mentioned in the second link in my config.php,
> and I tried making a copy of my config.php with all of the included
> recipes commented out, and still have the problem.
> 
> If I open dev mode in Firefox, I can see the PHPSESSID and its value.
> If I go to another page that requires the login, I see that the
> session ID in the cooking remains the same. So it seems that the
> session is being maintained?
> 
> Not sure what else to look at now.
> 
> Thanks,
> 
> On Thu, Sep 21, 2023 at 4:01 AM Petko Yotov <[email protected]> wrote:
> 
>> I'd also check if there are any PHP errors or warnings near the top
>> of the page, or in the html source. A PHP version update on the
>> hosting may cause this before the headers are sent, which may
>> prevent the browser from saving the session cookie.
>> 
>> Petko
>> 
>> On September 21, 2023 9:21:55 AM GMT+02:00, Simon
>> <[email protected]> wrote:
>> 
>> There are a couple of answers on
>> PmWiki | PmWiki / Troubleshooting [1]
>> 
>> Including Why is PmWiki prompting me multiple times for a password
>> I've already entered?
>> and
>> I have to log in twice
>> 
>> [1]that may help
>> 
>> Simon
>> 
>> On Thu, 21 Sept 2023 at 08:26, Jeff Henry <[email protected]> wrote:
>> 
>> Hello,
>> 
>> 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 [2]. 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? Thanks,
>> 
>> --
>> Jeff Henry _______________________________________________
>> pmwiki-users mailing list
>> [email protected]
>> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
> 
> --
> Jeff Henry
> 
> Links:
> ------
> [1] https://www.pmwiki.org/wiki/PmWiki/Troubleshooting
> [2] 
> https://www.pmwiki.org/wiki/PmWiki/SecurityVariables#DefaultPasswords

_______________________________________________
pmwiki-users mailing list
[email protected]
http://www.pmichaud.com/mailman/listinfo/pmwiki-users