[pmwiki-users] Repeated prompts for passwords?

Tue Sep 26 06:27:19 PDT 2023

Hello Petko,

I finally got this resolved. After turning on $EnableDiag, I started seeing
these messages:

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

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

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!

I appreciate your help in getting to a resolution!
Thanks,
Jeff.

On Fri, Sep 22, 2023 at 3:07 PM Petko Yotov <5ko at 5ko.fr> wrote:

> 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
>

-- 
Jeff Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20230926/8bf16d6f/attachment.html>