[pmwiki-users] Redundant logins

[Kenneth Forsbäck]

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.

Kenneth

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