[pmwiki-users] Redundant logins

[Petko Yotov]

On Sunday 06 February 2011 05:09:58, Kenneth Forsbäck wrote :
> My last working version was 2.2.19, 

I tried your configuration - it works fine for me - I can edit, and I only 
need to log in once. The changes between 2.2.19 and 2.2.23 are unlikely to be 
related to your login problem.

If your "t" skin has *.php files, there might be something that I didn't test, 
but if you only have *.tmpl and *.css files, the skin is fine.

Can you change your admin password to something different, 5 or more 
characters, then try again?


> I had newer versions (vanilla) on my offline server but never uploaded them.

Does the version 2.2.23 work on your offline server?


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

Sometimes hosting providers upgrade the PHP software without informing their 
clients. A new PHP version is different and may cause a script to break - if 
it is the case, we need to infestigate it and fix it. But in this case, I 
suspect version 2.2.19 wouldn't work either.


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

Those look fine, I see nothing that could break authentications.


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

If nothing helps, you can always revert to 2.2.19. Older PmWiki versions can 
be found here:

  http://www.pmwiki.org/pub/pmwiki/

But if 2.2.19 does work, I'd really like to know why. :-)

Petko

> >> 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.
...
> > 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);