[pmwiki-users] Redundant logins

[Kenneth Forsbäck]

My last working version was 2.2.19, I had newer versions (vanilla) on my 
offline server but never uploaded them.

I think I can safely rule out browser and server problems, as nothing 
has changed. I also tried it with Opera but had the same problem.

I am using two addons: "titledictindex" and one of my own (not pretty, 
but it works; attached file [codecogs.php]). I've also attached my 
config.php.

Even when I use a vanilla config (from docs/) and use DefaultPasswords 
it still asks me again and again. Quite puzzling.

Kenneth

On 2011-02-05 9:17 am, Petko Yotov wrote:
>> Has the authentication changed in 2.2.23?
>
> No, but problems have been reported when in config.php $EnablePageVarAuth is
> set to something different from 0. It was introduced in 2.2.22 and disabled by
> default in 2.2.23. This variable is not required.
>
> What was your previous working version before you upgraded to 2.2.23 (and
> before 2.2.22)? What kind of authentication are you using (AuthUser,
> DefaultPasswords)?
>
>> Whenever I view a page (e.g. SiteAdmin or ?action=edit) that requires
>> authentication, it always shows the login form even if I'm already
>> logged in.
>>
>> This happens again, and again, and again, no matter how many times I log
>> in, log out, clear cookies, or force a full refresh.
>
> If pmwiki suddenly starts to act like this, there could be three kinds of
> causes: a PmWiki upgrade, a browser upgrade, or a server up/downgrade.
>
> A new PmWiki version could have broken something - even if we use the latest
> version and we fix bugs as we find them, this is a possibility. If you know
> which version used to work fine, we could see what changed since then.
>
> A new recipe or recipe version version could also be responsible.
>
> After an upgrade, your browser might have stopped accepting cookies. This is
> rare, and in that case, you wouldn't be able to log into other password-
> protected websites like a webmail or a forum. You could test your wiki with a
> different browser or from a different computer to see if it works.
>
> A change in your hosting server software could have caused this. A while ago,
> we needed to adapt PmWiki to work with the new PHP 5.3 versions which had many
> changes. We fixed all problems that we found (except one with very short
> passwords on some PHP versions on Windows) but there could be more. If we
> could look at your wiki and test it, we may find the problem. It would be
> useful to enable the PmWiki diagnostics tools with such a line in config.php:
>
>    $EnableDiag = 1;
>
> Last problem that I think of is something could have caused the
> "session.save_path" directory to become write-protected. This is rare - could
> be a disk-full problem or a server/PHP misconfiguration. It should be possible
> to select your own directory for the session data near the beginning of
> config.php:
>
>    $SessionDir = "$WorkDir/.sessions";
>    mkdirp($SessionDir);
>    fixperms($SessionDir);
>    session_save_path($SessionDir);
>    unset($SessionDir);
>
> Petko
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: codecogs.php
URL: <http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20110206/d2fcad6e/attachment.asc>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20110206/d2fcad6e/attachment.html>