Administration not possible because login required each time

[raigl]

On a freshly installed 1.2 beta1, I cannot administrate the blog. The login with the given userid/password is accepted, the admin blog is displayed, with the correct admin username. However, whenever I want to acces any of the admin functions, the login screen comes again. German language selected.
Where should I search?

If I update from 1.1, same problem. If I install new, but reuse the database tables, login works.

[garvinhicking]

Hi!

When updating, it might be required to clean your session/user cookies to properly login to Serendipity. Can you instruct your browser to do that and try again?

Best regards,
Garvin

[raigl]

Hi Garvin,

no, removing cookies does not help. Tried with IE and Firefox.

Only one cookie, PHPSESSID, is created, and this works also for the
1.1 installation, which is howver no longer clean, as I installed 1.2 over it and than un-tared 1.1 again to have a working system

Is there any trace/debug option? Because this is still a test installation, I can modify some PHP code; but it is complex enough that I did not understand the authentication procedure immediately.

Bye,

Rainer

[garvinhicking]

Hi!

Are you using https or http to login? What are your php.ini session.* and cookie.* options? Which URL do you use to login (IP-adress, hostname, ...?)

When you login, are session files put into your session.save_path configured directory? Once you logged in and clicked on other menu items, can you see if the sesion file is updated or even deleted and a new one is added?

when you login, do you check the "remember me" box, or don't you?

Those are a lot of questions, but their answers might lead us to the clues. There sadly is no real debugging switch, only what one can gather by investigation the HTTP-Headers. Some "X-..." debugging headers are emitted there.

HTH,
Garvin

[raigl]

Well, we are gettin closer. I found the session save path, deleted all sessions information, logged in, and the session info was:

Code: Select all

SERVER_GENERATED_SID|b:1;no_smarty|N;serendipityLanguage|s:2:"de";author_token|s
:40:"4d624d9d755a50e0acf54a7a4baf80d3b5d2b499";serendipityUser|s:9:"webmaster";s
erendipityRealname|s:16:"Martin Muster";serendipityPassword|s:32:"ab9bf739cca
ee8b41d06dcd2ebc138fe";serendipityEmail|s:10:"a@b.de";serendipityAuthorid|s:
1:"1";serendipityUserlevel|s:3:"255";serendipityAuthedUser|b:1;serendipityRightP
ublish|s:1:"1";

After clicking "new entry" and the display of the login mask again, the contents was:

Code: Select all

SERVER_GENERATED_SID|b:1;no_smarty|N;

Version 1.1 gave:

Code: Select all

SERVER_GENERATED_SID|b:1;no_smarty|N;serendipityAuthedUser|b:1;HTTP_REFERER|s:11
9:"http://kerai/htdocs/CMS/serendipity/serendipity_admin.php?serendipity[adminMo
dule]=entries&serendipity[adminAction]=new";serendipityUser|s:9:"webmaster";sere
ndipityRealname|s:16:"Martin Muster";serendipityPassword|s:32:"ab9bf739ccaee8
b41d06dcd2ebc138fe";serendipityEmail|s:10:"a@b.de";serendipityAuthorid|s:1:"
1";serendipityUserlevel|s:3:"255";serendipityRightPublish|s:1:"1";

and did not change.

What's different is that the HTTP_REFERER is missing in 1.2.

Using PHP 5.1.6 and Apache2 on Xubuntu 6.10. PHP says session.referer_check is "no value".

While you think about it, I will find another system and try it out there. I am not sure I can manage it today, so you might well wait.

Rainer

[garvinhicking]

Hi!

Do you have the firefox LiveHTTPHeader extension installed? If so, could you log a process like this:

1. Complete logout
2. Fresh Login
3. Click on an admin link
4. Resulting re-login page

That should yield results on which HTTP headers are sent. It seems like your session is destroyed on each page call, and we need to find out why.

There are at some instances in the s9y code where that is done :

1. serendipity_config.inc.php lines 18 to 23 -- happens when no 'SERVER_GENERATED_SID' variable can be found in your session.

2. include/functions_config.inc.php, line 537 -- happens when the serendipity_authenticate_Author() function is called with invalid username/password. That can happen if you use HTTP authentication or if an old/stale cookie contains old/stale user information.

3. serendipity_admin.php line 33 - when no 'author_token' session variable exists in either session or cookie.

HTH,
Garvin

[raigl]

Just installed a fresh xubuntu-6.10 on a (virtual) machine, and could reproduce the effect. System like the one above.

Rainer

[garvinhicking]

Hi!

Can you also please answer my other questions in the original posting above:

Are you using https or http to login? What are your php.ini session.* and cookie.* options? Which URL do you use to login (IP-adress, hostname, ...?)
when you login, do you check the "remember me" box, or don't you?

Regards,
Garvin

[raigl]

Using live http headers, I could see that the cookies were never set, because I used a local server in the same domain without domain dots:

Code: Select all

http://server/serendipity/...

instead of a fully qualified domain name, FQDN:

Code: Select all

http://server.my.domain.de/serendipity/...

Apparently 1.2 uses not only the PHPSESSID (which could collide with other PHP applications if path=/), but specific cookies using the path and domain keywords. The latter, however, is only matched, if it contains at least three periods, see http://wp.netscape.com/newsref/std/cookie_spec.html.

Once I used a FQDN, it works. I.E., in the config, the 'baseURL' has to use a FQDN (or the use of the domain keyword dropped in the next version)

Garvin, thanks for your patience and hints,
Rainer

[garvinhicking]

Hi!

Ah, good catch. I always forget that one.

I committed this:

http://svn.berlios.de/viewcvs/serendipi ... 4&view=rev

This should ignore the HTTP host when no 'dot' is contained. I believe when using a single dot already, browsers accept cookies, so that's we we check only for a single dot now.

Maybe you could try this patch and tell me if it wors?

[raigl]

Hi Garvin,

yes, the patch works fine.

Should learn to use CVS versions...

Best,
Rainer