still on login screen

[manner]

hi,
i have a problem with rc2 installation. when i login to imap server, RC is stil on login screen, but in server logs was login - logout messages (with no errors) in 'console' file only:

[19-Jan-2008 00:37:26 +0100]: * CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT Q
cp01 OK CAPABILITY completed
Tried PLAIN: Resource id #32

all looks good, and no working. anybody help me?
thx

[jasonar]

This might happen if you change the RC index name to like "mail.php" or "accounts.php" because the login form is set to post at the index. So if your your file name is changed, post back and I'll tell you how to fix this.

[tendays]

Hello, I seem to have the same problem, so am posting my observations in the same thread.

My configuration (everything running on the same machine)

OpenBSD 3.6
Mysql 4.0.20
Apache/1.3.29 (Unix) DAV/1.0.3 PHP/4.3.8 mod_ssl/2.8.16 OpenSSL/0.9.7d
courier-imap 3.0.5

So, I installed Roundcube rc2 according to the instructions.
If I try to login with a bad username/pass, the "Login failed" box appears, as expected.
If I try to login with a correct username/pass, the page gets redirected to ?_task=mail, but it shows the login form again. I have not renamed any file.

I put a bunch of debug statements in the code to try and find out where it happens. My observations so far:

It seems that it is unable to retrieve the session information (i.e. $_SESSION is empty after session_start() is called), which is why it displays the login form again (as, after redirecting, it "forgot" I was logged in).
However, looking at the "session" table, I can see it has been properly populated (with user_id set to whichever user I tried logging as).
So, I could go on putting debug output statements here and there but I thought I'd ask you if you have any idea what the problem might be?

Thanks.

EDIT: By the way, nothing appears in the error log

[corpo]

Sounds to me that for one reason or another, your session cookie is not being set (on the client). This could be the browser itself being set to disable cookies, or it could be a configuration problem of php itself, or some config problem with roundcube itself. Easiest way to determine whether or not it's specific to roundcube is to throw something like this on your server:

Code: [Select]

<?php
session_start();

if($_REQUEST['test']=='test' && $_SESSION{&quot;test&quot;}==1){
    ?> session set successfully <?
}else{
    $_SESSION[&quot;test&quot;]=1;
    ?><form action=?><input type='submit' value='test' name='test'/></form><?
}
?>

...and name it test.php or some such - and visit it with a browser. If it doesn't render "session set successfully" after you click the button, the problem is not specific to roundcube, it's gotta be either the client or the php config.

[ek]

Hello, all. New to this forum. Great bit of software (I've used it in the past).

With the latest release I seem to be having the exact same problem here. I went a head and played around with a few things for a while but figured I wouldn't re-invent the wheel if I didn't have to.

Has anyone found a solution to this? If so, can you please post it?

RE: corpo

Code: [Select]

Sounds to me that for one reason or another, your session cookie is not being set (on the client). This could be the browser itself being set to disable cookies, or it could be a configuration problem of php itself, or some config problem with roundcube itself. Easiest way to determine whether or not it's specific to roundcube is to throw something like this on your server:


<?php
session_start();

if($_REQUEST['test']=='test' && $_SESSION{&quot;test&quot;}==1){
    ?> session set successfully <?
}else{
    $_SESSION[&quot;test&quot;]=1;
    ?><form action=?><input type='submit' value='test' name='test'/></form><?
}
?>



...and name it test.php or some such - and visit it with a browser. If it doesn't render &quot;session set successfully&quot; after you click the button, the problem is not specific to roundcube, it's gotta be either the client or the php config.

Tried this and the results came through as expected. "session set successfully" was recieved without a hitch. Perhaps you have some more ideas I could try in order to determine what is wrong?

Regards
Janky Jay, III

[tendays]

Okay, I haven't yet found the problem but am getting closer.

When logging in , it apparently tries to expire the old cookie session id (which was generated when the login form was displayed), and set a new one. But this doesn't work, for some reason, and when the browser gets redirected to ./?_task=mail, the browser doesn't send any cookie at all!

It seems that two Set-Cookie headers are sent to the browser along with the redirect request (in response to the login POST request), one with the OLD session id, with expiration set to a few hours from now() and one with the NEW session id with expiration set to January 1970.

Notice the problem? :-)

Strangely, the setcookie() function in session.inc is called with the new session id and lifetime set to some non-zero value (14400)... Could that be a php problem then?

Note that I know that cookies are working, normally, because:
1) Other php applications on the same server work correctly (and set+receive the cookies correctly)
2) When GETting the login form, I get *one* Set-Cookie header with expiration set correctly, and when submitting the form, that session cookie is correctly sent to the server (I print_r'red the $_COOKIE table from index.php to check that).

If any roundcube developer reads this: Is there any particular reason you are using custom session handlers? Would I break something if I just commented out all custom cookie and session handling code, and dropped the "session" table?

Thanks.

[till]

I see your reasoning, but I just installed RoundCube and it works?

When you check this:
http://trac.roundcube.net/browser/trunk/roundcubemail/index.php#L69

Where exactly is a custom session handler?

(I subscribed to this topic, so keep it coming.)

[tendays]

I see your reasoning, but I just installed RoundCube and it works?

Well you're luckier than I am :-)

When you check this:
http://trac.roundcube.net/browser/trunk/roundcubemail/index.php#L69

Where exactly is a custom session handler?

(I subscribed to this topic, so keep it coming.)

The custom session handler is registered there (see session_set_save_handler() at the bottom of the file) : http://trac.roundcube.net/browser/trunk/roundcubemail/program/include/session.inc

*BUT* I see they changed the sess_regenerate_id() function since I downloaded it. I'm almost sure that it fixes my problem (can't check now - will update tonight).

Thanks.

[till]

I see your reasoning, but I just installed RoundCube and it works?

Well you're luckier than I am :-)

Well, maybe.

When you check this:
http://trac.roundcube.net/browser/trunk/roundcubemail/index.php#L69

Where exactly is a custom session handler?

(I subscribed to this topic, so keep it coming.)

The custom session handler is registered there (see session_set_save_handler() at the bottom of the file) : http://trac.roundcube.net/browser/trunk/roundcubemail/program/include/session.inc

*BUT* I see they changed the sess_regenerate_id() function since I downloaded it. I'm almost sure that it fixes my problem (can't check now - will update tonight).

Thanks.

Ok, sounds good. I totally forgot that part.

I think one of the reasons to save sessions to a database allow easy access to it when you run RoundCube on multiple servers etc.. Point taken this is not the most common use-case but there are some ISPs who that. I also put this on my todo list to replace this code with something more generic and configurable later on.

Let me know how your update turns out.

Thanks,
Till

P.S.
Is there a ticket on trac about this? Just curious so we might be able to close it for 0.1-stable.

[ek]

Yeah. Same deal. Just to test, I commented out just the 'sess_regenerate_id()' in the index.php file, everything works fine. I'll try the SVN now and see what I can come up with...

EDIT: Nope. Just tested and it does the exact same thing... Shame!

NEW EDIT!: Disabling 'session.auto_start' in php.ini (Or via an .htaccess file) fixes this for me. Related to ticket #1484437 located at http://trac.roundcube.net/ticket/1484437 . Thanks, till and the_glu!

[tendays]

Solved!

The custom session handler is registered there (see session_set_save_handler() at the bottom of the file) : http://trac.roundcube.net/browser/trunk/roundcubemail/program/include/session.inc

*BUT* I see they changed the sess_regenerate_id() function since I downloaded it. I'm almost sure that it fixes my problem (can't check now - will update tonight).

Thanks.

Ok, sounds good. I totally forgot that part.

I think one of the reasons to save sessions to a database allow easy access to it when you run RoundCube on multiple servers etc.. Point taken this is not the most common use-case but there are some ISPs who that. I also put this on my todo list to replace this code with something more generic and configurable later on.

I see. Not useful for me then, but doesn't hurt (anymore) either.

Let me know how your update turns out.

So, yes, as expected, updating to the latest svn fixed the problem - it was indeed a problem with the cookie expiration time, which was miscalculated.

P.S.
Is there a ticket on trac about this? Just curious so we might be able to close it for 0.1-stable.

I haven't put one. Maybe the OP has...

Thanks! I made a few tests and everything seems to work well so far.

[till]

Hi,

this is now fixed in SVN (Subversion).

If you are suffering from the same bug, you will need to use the SVN version of RoundCube or wait for 0.1-stable release.

Wondering how to get SVN? - http://trac.roundcube.net/wiki/Dev_SVN

Thanks!
Till