Topic: Users cannot log in to webmail after upgrade to 7.4

[Paperguides]

I have reports from two of the site I updated over the weekend that an individual user cannot now login to Webmail. The error message is:

A fatal error has occurred

Session cookies will not work without a FQDN and with a non-empty 
cookie domain. Either use a fully qualified domain name like 
"http://www.example.com" instead of "http://example" only, or set the 
cookie domain in the Horde configuration to an empty value, or enable 
non-cookie (url-based) sessions in the Horde configuration.

Why does this only affect a few users and how do I fix it?

Thanks

Tony

[gzartman]

I have reports from two of the site I updated over the weekend that an individual user cannot now login to Webmail. The error message is:

A fatal error has occurred

Please report errors with SME to the bug tracker. http://bugs.contribs.org/  If there is a problem with SME, then it starts the ball rolling on getting it fixed.  If it isn't a problem with SME, but something you've done; then you are more likely to get an answer that will help you fix the problem.

Before you file your report, have a look at the httpd error-log file:  /var/log/httpd/error_log.  Scroll down through the log file and look for entries related to the failed webmail login.  Report these error log entries in your bug report.

[Stefano]

Hi

according to some tests it seems due to dns problems.

verify your SME does name resolution..

HTH
Ciao

Stefano

[caf]

I have the same I updated over the weekend that an individual user cannot now login to Webmail. The error message is:

A fatal error has occurred

Session cookies will not work without a FQDN and with a non-empty
cookie domain. Either use a fully qualified domain name like
"http://www.example.com" instead of "http://example" only, or set the
cookie domain in the Horde configuration to an empty value, or enable
non-cookie (url-based) sessions in the Horde configuration.

Why does this only affect a few users and how do I fix it?

Thanks

JPVP

[christian]

I have seen this as well where a user references the internal name of the server instead of the fully qualified name.

For example assume your server internally is called "bert" but your domain is called "ernie.com". prior to 7.4 users could access via https://bert/webmail. However in 7.4 this will fail.

If your internal users instead uses https://bert.ernie.com/webmail then it will work fine.

I don't know why this broke in 7.4, perhaps that is a bug and I assume OP has filed a bug report.
 

[caf]

when I try :
https://mail.caf.local/webmail -> I have a error
https://caf/webmail -> i have a error on SME 7.4, but OK in 7.3
https://192.168.1.1/webmail -> OK - 192.168.1.1 adress of the server

I have this error on 2 servers, but on 1 server, I dont have this error if I do https://mail.caf2.local/webmail, but https://caf2/webmail do a error.

Thanks.

[christian]

I was expecting OP to identify the bug he is hopefully opening. Short of that, can you do a quick search and add your notes to the bug if it exists or create a new bug if does not exist?

Other than allowing us to recognize that there is a common issue, it is the bug report which will actually get it fixed or properly diagnosed.

[linuxhelp]

Is SOLVED see Bug-Tracker SME!!

since 4 weeks!

Bug number
http://bugs.contribs.org/show_bug.cgi?id=4787

[christian]

Is SOLVED see Bug-Tracker SME!!

I'm confused. This bug shows a work around as a solution using a custom template. As this is a standard SME package, shouldn't this be fixed in the standard template?

[cactus]

I'm confused. This bug shows a work around as a solution using a custom template. As this is a standard SME package, shouldn't this be fixed in the standard template?

And I am surprised you are doing the follow-up (only) here. Please add remarks like this to the bugreport. Thanks.

[christian]

fair enough. I was looking for clarification but yes, I suppose I should do that in the bug tracker too.

By the fact that you are surprised, I assume I am otherwise reasonably well behaved.   

[judgej]

I raised a similar problem in Bugzilla a few versions ago, and it was fixed in a patch. Seems that something like it is back. I can't find the bug now, but it relates to the number of dots used in the cookie domain. There is no reason why sessions should require a FQDN to work, so long as the cookie domain is set correctly, and that means with the correct number of leading and trailing dots. I suspect the problem is the way the cookie domain is formed.

I hit the same problem today, when one of my users needed to use webmail for the first time since the 7.4 upgrade. "It gives me a scary error message!", and that is after getting past Firefox's dire "death to you and your unborn if you accept this certificate" warnings.

-- Jason

Edit: I've just read the bug. This line explains it all:

$conf['cookie']['domain'] = $_SERVER['SERVER_NAME'];

You cannot use the server name as the cookie domain, without *first* suffixing it with a dot:

$conf['cookie']['domain'] = $_SERVER['SERVER_NAME'] . '.';

When I last raised it, the [same] problem was with the main server-manager pages, rather than Horde.

[cactus]

Edit: I've just read the bug. This line explains it all:

A referral to the bug would have been nice so users can judge the context, could you add it to this thread?

[judgej]

A referral to the bug would have been nice so users can judge the context, could you add it to this thread?

The bug posted above:

http://bugs.contribs.org/show_bug.cgi?id=4787

I can't find the one I orginally raised, which is strange. Not sure if it has been locked up as a 'security' bug or something, or purged.

[David Harper]

The missing bug may be a result of the recent server issues.