[pmwiki-users] Redundant logins

Kenneth Forsbäck kenneth.forsback at bob.fi
Sat Feb 5 22:55:02 CST 2011

Whoops. The codecogs script was actually an older one where I messed up 
the conditional order, so it always fetched the content before checking 
of the file exists.

Other than that, not much of a difference.


On 2011-02-06 6:09 am, Kenneth Forsbäck wrote:
> 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
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users

More information about the pmwiki-users mailing list