[BUG] Failed login in Chrome

[Petertjuh360]

Hello,

One of my clients is experiencing a login problem with Chrome. He gets an error message with the message that he uses invalid details. When he uses Firefox, he can login without any error message. He said that this problem occurs at another provider with DirectAdmin too.

DirectAdmin in debug provides this information:

Debug mode. Level 2000

DirectAdmin 1.48.3
Accepting Connections on port 2222
Sockets::handshake - begin
Sockets::handshake - end
/CMD_LOGIN
 0: Accept-Encoding: gzip, deflate
 1: Accept-Language: en-GB,en;q=0.8,en-US;q=0.6,nl;q=0.4,de-DE;q=0.2,de;q=0.2
 2: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
 3: Cache-Control: max-age=0
 4: Connection: keep-alive
 5: Content-Length: 49
 6: Content-Type: application/x-www-form-urlencoded
 7: Cookie: session=
 8: HTTPS: 1
 9: Host: www.[CENSORED].nl:2222
10: Origin: http://www.[CENSORED].nl:2222
11: Referer: http://www.[CENSORED].nl:2222/CMD_LOGIN
12: User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36
13: X-CookiesOK: I explicitly accept all cookies
Post string: referer=%2F&username=[CENSORED]&password=[CENSORED]
FormCheck::isDomain: denied on null or empty domain: (null)

 

[DirectAdmin Support]

1) For Chrome, tell him to press Ctrl - J to open the debug mode.

2) Then go to the "network" tab.

3) Load (or reload) the login page, so it shows the info..
Click on the / page, and look at the "Response Headers" section, where we're looking for this:

[COLOR=#545454][FONT=Segoe UI][B]Set-Cookie:[/B][/FONT][/COLOR]
[FONT=Consolas]session=; path=/; expires=Fri, 04 Sep 2015 00:05:56 GMT; secure; HttpOnly[/FONT]

4) Then enter the user/pass and login normally. We're then looking for this on the CMD_LOGIN page:

[COLOR=#545454][FONT=Segoe UI][B]Set-Cookie:[/B][/FONT][/COLOR]
[FONT=Consolas]session=ra7zEOx1ynvtcBD20H0MOuIWRXQeBIr2EyzcKsdJiWBIhNOhcN30FJUersJ2B84N; path=/; expires=Fri, 04 Sep 2015 00:08:33 GMT; secure; HttpOnly[/FONT]

5) If you DO see DA setting a session value, then the next request to DA should include that cookie.
In the "Request Headers", you should see that cookie being included in the request, under the "Cookie:" header.

------------

A recent issue has to do with the date of the server versus the date of the client. If they're out of whack, the session cookie would expire immediately as it's set, so the client wouldn't send it back to DA.

Recent changes to DA for cookies:
1.48.3: FreeBSD: http://www.directadmin.com/features.php?id=1768
1.48.2: All: http://www.directadmin.com/features.php?id=1765
1.48.1: All: http://www.directadmin.com/features.php?id=1762

You can actually shut off the "expiry" mode to confirm if it's a date expiry issue or not.
If you want to shut of expiry cookies, thus just relying on closing the browser, add:

use_cookie_expires=0[code]to your directadmin.conf and restart DA.
The server-side session timeout still applies. The above just applies to how long a session cookie can live in the browser.
When enabled, it allows you to close the browser, re-open it and still be logged into DA, as long as you're still within the server-side session timeout.

John