Big Trouble with Directadmin Login

I have the same problem
I first thought that the update procedure may have been failed that the login is not working
I reinstalled the directadmin and the problem still exists
Please someone help me to downgrade

Thanks
 
woshka said:
I have the same problem
I first thought that the update procedure may have been failed that the login is not working
I reinstalled the directadmin and the problem still exists
Please someone help me to downgrade

Thanks
Click to expand...
Hi, yes its Because of new Update and we are waiting for new release (1.48.2) But Still It is not known what is the problem, So Directadmin Support are working on it.if you want to DownGrade you should find the 1.47 binaries
hope my comments help you
Regards
 
So is this just happening with certain browsers? I get the differences in the RFCs mentioned above but I have several machines all running 1.48.1 but haven't seen the issue.

What seems to be the common denominator?
 
webquarry said:
So is this just happening with certain browsers? I get the differences in the RFCs mentioned above but I have several machines all running 1.48.1 but haven't seen the issue.

What seems to be the common denominator?
Click to expand...

I think its not because of the browsers , and this Problem doesnt happend for everyone , Just some clients usually with PC!
 
dibawebhost said:
I think its not because of the browsers , and this Problem doesnt happend for everyone , Just some clients usually with PC!
Click to expand...

So it is OS related? I'm running on the latest MacOS right now. I'll try windoze...

Seems to be a problem on windoze 8.1.

Here are the browsers I tried:

Explorer: Fails. No surprise there. Never use Explorer.
Chrome: Seems to work fine
Firefox: Seems to work fine.

Is everyone that is having trouble only using Explorer?
 
webquarry said:
So it is OS related? I'm running on the latest MacOS right now. I'll try windoze...

Seems to be a problem on windoze 8.1.

Here are the browsers I tried:

Explorer: Fails. No surprise there. Never use Explorer.
Chrome: Seems to work fine
Firefox: Seems to work fine.

Is everyone that is having trouble only using Explorer?
Click to expand...
Im not sure! Bcause My friend with Windows OS and Firefox could Login Succesfully, But I couldnt! Im waiting for Mr John to solve this problem and more explains!
 
I've just tested Windows 8 with IE 11, and have no issues (to confirm, I'm using the new binaries with the "spaces" in the date format)
So if someone can please include more definite information as to exactly which client OS and browser version is used, that would help greatly, as I've yet to duplicate the issue.
Also make sure your computer's date is correct.. as the expiry is an absolute date.. meaning if your computer's date is wrong, your session cookie may expire instantly.

I've just uploaded a new set of pre-release binaries, but added a new option "use_cookie_expires", so the "expires" set-cookie option can be disabled.
Default is 1, which is enabled, so set it to 0 if you want to disable the "expires" option.

If you want to try this, so we can confirm if the expires is affecting the set of the cookie for the given browser

1) Grab the latest pre-release binaries.


2) Confirm the compile date shows June 24th at around 15:10:
Code: 
cd /usr/local/directadmin
./directadmin o
3) Add this option:
Code: 
echo "use_cookie_expires=0" >> conf/directadmin.conf
4) Confirm it's set:
Code: 
./directadmin c | grep use_cookie_expires
to ensure it's set to 0.


5) Restart DA forcefully to ensure the new binaries are running:
Code: 
killall -9 directadmin
killall -9 directadmin
./directadmin b2000
then try again, to see if the login works.


----

What we're looking for for the login process is:

A) Load the login page, the session= cookie will either not exist, or be blank, eg:
Code: 
Cookie: session=

B) Enter your User/Pass, and click "Login", and you should see this in the request:
Code: 
Session file written: /usr/local/directadmin/data/sessions/da_sess_DjTO8loffOqZSmjs7b7GoLxyxH2dEj6PRZlXIZAyv0VNkCDqnK6bg1YbJYEUFIth
setLocation: http://1.2.3.4:2222/
This is also where DA sends back the set-cookie to load in it. Check your browser (if has the ability) to show you what cookies are current set.
A location redirect would go along with that, point you to where you were heading to... usually /. The request passed to DA for this request will still show "session=", but after the request is done, the browser should have it set and filled.

C) Now the browser requests / again, but should be sending the cookie:
Code: 
Cookie: session=DjTO8loffOqZSmjs7b7GoLxyxH2dEj6PRZlXIZAyv0VNkCDqnK6bg1YbJYEUFIth

----

So far, we've narrowed it down to the browser not sending back the session cookie in C. I've still not received confirmation as to exactly which browser is affected.. perhaps I'm using a different version of IE?
But adding the use_cookie_expires=0 would probably solve it, but prevents the "trust this device" option from working beyond closing your browser.



----

The new binaries also have debug code, level 3900, which will spit out exactly which "Set-Cookie" header is sent to the browser.
That level gets a bit messy with a lot of output, so I usually do:
Code: 
./directadmin b3900 | grep Set-Cookie
assuming you've already run it at a lower level and know what relevant bits would be showing up (as the grep hides everything else)

John
 
Oh my God ! I set My Pc time and my Problem Solved:O my PC date was in June 26 ! and I corrected it!
Apologize directAdmin!:(
 
Last edited:
I had the same problem after upgrade and I find what caused it after searching about 5 hours and useless solutions...

I have correct system time
My PC time is 25th June but always return to new login page after correct login details.

After I changed my PC time to 24th the problem gone!

So what I think caused the problem is mismatch time between local PC and VPS time (VPS based on netherland with some hours before my PC time) so by this way I temporary bypass the session bug on new upgrade DA version.

Hope this helps admin and other clients:).
 
What I think I'll do.. is, since the server itself will always be correct in terms of session duration, I'll set the client's session cookie to be say 10x the session expiry time.
This will allow for more errors in terms of strange time offsets, but won't affect actual session time, as DA would delete the session file on the server once it's done, forcing a new login anyway.

John
 
I have the correct time set
latest opera browser
tested on Chrome too
tested on windows 8 and windows 2008 R2 64bit
here is the log

Sockets::handshake - begin
Sockets::handshake - end
/
0: Accept-Encoding: gzip
1: Accept-Language: en-US,en;q=0.8
2: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
3: Host: xxx:2222
4: User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36 OPR/30.0.1835.59
didn't find the encrytped text
Sockets::handshake - begin
Sockets::handshake - end
/CMD_LOGIN
0: Accept-Encoding: gzip
1: Accept-Language: en-US,en;q=0.8
2: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
3: Cache-Control: max-age=0
4: Content-Length: 44
5: Content-Type: application/x-www-form-urlencoded
6: Host: xxx:2222
7: Origin: http://xxx:2222
8: Referer: http://xxx:2222/
9: User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36 OPR/30.0.1835.59
Post string: referer=%2F&username=xxx&password=xxx
Session file written: /usr/local/directadmin/data/sessions/da_sess_xxx
setLocation: http://xxx:2222/
setLocation: http://xxx:2222/
sent Location: http://xxx:2222/
Sockets::handshake - begin
Sockets::handshake - end
/
0: Accept-Encoding: gzip
1: Accept-Language: en-US,en;q=0.8
2: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
3: Cache-Control: max-age=0
4: Host: xxx:2222
5: Referer: http://xxx:2222/
6: User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36 OPR/xxx
didn't find the encrytped text
Click to expand...
 
Last edited by a moderator:
Hello,

Since DirectAdmin 1.48.2 we have problems in Google Chrome. (All other browsers works good)
login does not work in Google Chrome.

Problem running on:

FreeBSD 9.x (all our FreeBSD servers)
Directadmin 1.48.2
Custombuild 1.2

Cliënt:
Windows 8.1
Chrome version: 43.0.2357.130 m

No problems at:

Debian 7.x
DirectAdmin 1.48.2
Custombuild 2.x

Cliënt:
Windows 8.1
Chrome version: 43.0.2357.130 m

Problem solved by:
echo "use_cookie_expires=0" >> conf/directadmin.conf
 
@davydvries

Can you try these options instead:
use_cookie_expires=1
session_cookie_multiplier=744

which should give you a full month of offset for the cookie expires.

A) If that works, then we know it's an issue with one of the times either on the server or the client.

B) If not.. then either the time error is more than a month, or the browser is not liking the format of the cookie expires (I use windows 8 + chrome Version 43.0.2357.130 m, and have no issues)
Also possible the browser is set to not allows cookies in that format? I'm not sure (Again, not able to duplicate so far).

For Chrome, type:
ctrl-shif-j
go to "Resources"
click the Cookies arrow to expand
click your hostname
check to see what the cookie named "session" has set for "expires / max-age"

Also see my Post #27, to see the they last command involving "grep Set-Cookie"
Run that to confirm what the expires is being set to.

If that is good, then it still points to a time issue somewhere (server or client) or browser issue where it's not accepting the cookie that contains the expires.

John
 
Hi John,

Thanks for your answer!

A) If that works, then we know it's an issue with one of the times either on the server or the client.

Yes, that works! I see on FreeBSD Servers:

SFrNgTvZ.jpg


With the default value (use_cookie_expires=1) I see on FreeBSD servers:

VFZVtmAg.jpg


With the default value (use_cookie_expires=1) I see on Debian servers:

http://static.afbeeldinguploaden.nl/1506/110965/pFONPxD3.jpg
 
Hi John,

Thanks for your answer!

Can you try these options instead:
A) If that works, then we know it's an issue with one of the times either on the server or the client.

Yes, that works! I see in Google Chrome (FreeBSD server):

Code: 
Name: session
Value: 
Domain: <SERVERNAME>
Path: /
Expires / Max-Age: 2015-07-02T09:09:01.000Z
Size: 7
HTTP: check mark
Secure: check mark

On FreeBSD servers with the option use_cookie_expires=1 I see:

Code: 
This site has no cookies.

On Debian servers with the option use_cookie_expires=1 I see:

Code: 
Name: session
Value: 
Domain: <SERVERNAME>
Path: /
Expires / Max-Age: 2015-06-27T09:14:06.000Z
Size: 7
HTTP: check mark
Secure: check mark
 
DirectAdmin Support said:
@davydvries

Can you try these options instead:
use_cookie_expires=1
session_cookie_multiplier=744

which should give you a full month of offset for the cookie expires.

A) If that works, then we know it's an issue with one of the times either on the server or the client.

For Chrome, type:
ctrl-shif-j
go to "Resources"
click the Cookies arrow to expand
click your hostname
check to see what the cookie named "session" has set for "expires / max-age"

John
Click to expand...

Hi John,

Thanks for your answer!

Can you try these options instead:
A) If that works, then we know it's an issue with one of the times either on the server or the client.

Yes, that works! I see in Google Chrome (FreeBSD server):

Code: 
Name: session
Value: 
Domain: <SERVERNAME>
Path: /
Expires / Max-Age: 2015-07-02T09:09:01.000Z
Size: 7
HTTP: check mark
Secure: check mark

On FreeBSD servers with the option use_cookie_expires=1 I see:

Code: 
This site has no cookies.

On Debian servers with the option use_cookie_expires=1 I see:

Code: 
Name: session
Value: 
Domain: <SERVERNAME>
Path: /
Expires / Max-Age: 2015-06-27T09:14:06.000Z
Size: 7
HTTP: check mark
Secure: check mark
 
Thanks for the info.
I believe the issue was that Linux allows strftime to use %02d for the day, but FreeBSD does not, causing "Mon" to show up as "2d" instead.
It also double pads that with 0s anyway, so I didn't need to do it in the first place.
Sorry for the bug!

This would show you the error, if you want to see it:
Code: 
killall -9 directadmin
./directadmin b4000 | grep Set-Cookie
to see what DA is setting.

I've uploaded the pre-release fix now.
I've also updated the 1.48.2 install packs with the fix (for now, so new installs are not affected), but will still release 1.48.3 shortly with the proper fix.

If anyone cares to confirm this with the pre-release binaries, that would put my brain at ease :)
I have tested and confirmed it does fix it on our FreeBSD 9 test box.

John
 
Can you elaborate on that?
1) Are you not able to add them?
2) Are they added by not running?
3) Is crond running?
4) Check the email for the User account that calls them to get all output.

John
 
You must log in or register to reply here.
Back
Top