[pmwiki-users] Repeated prompts for passwords?
Petko Yotov
5ko at 5ko.fr
Fri Sep 22 12:07:31 PDT 2023
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 <5ko at 5ko.fr> 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
>> <nzskiwi at gmail.com> 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 <jbhenry at gmail.com> 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
>> pmwiki-users at pmichaud.com
>> 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
More information about the pmwiki-users
mailing list