Jump to content

Recommended Posts

Posted

After updating my server to the latest OpenSSL to patch the Heartbleed vulnerability (and yum update everything else), all works fine EXCEPT the CC admin login doesn't work on IE, Opera (win and mac) and Safari.  Works fine in Chrome and Firefox.

 

I updated to 5.2.9 and that didn't help. (php 5.4.27)

 

The affected browsers don't throw any error, they just clear the input text fields when the login button is pushed and nothing happens.

 

This just started today and I did the server updates yesterday so I am wondering what correlation there may be here.

 

No other login interfaces that I have for clients have been affected, only CubeCart's admin login and only in IE, Opera and Safari.  My own admin program logins work and so does WordPress.

 

Any ideas about what this may be or if it is related to the OpenSSL patch?  I do have the site secured with a valid certificate.

 

Thanks

Posted

I have found that CubeCart's (CC527+) front-end will show a message about not a valid user/pass. CC's admin login checks that as well, but every form has a hidden element named "token". You can see this when you ask the browser to show the HTML source.

 

If CubeCart has a different token than what the form will submit, CubeCart will silently disregard the form submission - whatever the form was for - and send back the dashboard page.

 

Now, that does not mean the behavior you describe is caused by what I have just described. To see what may be happening, we need to make sure the browser is actually sending the form data and CubeCart is sending back a new page.

 

When using IE, press the keyboard F12. You should see a diagnostic panel at the bottom of the window. Click on the Network icon (a router with WiFi signals). You may have to submit the form once again. If there is no activity, then there is a problem with the browser's behavior. If there is a POST line, select it, click Details, and look at the Request Body - just to see what is there.

Posted

There is no activity.  But, as I said, this is the case with IE, Safari and Opera (win & mac).

No problems with Firefox and Chrome on both win & mac.

 

This is the case on ALL systems from various ISP's in different locations.

 

All of my CC store clients report this in different parts of the country.

 

Something isn't playing nice with these browser engines in the CC login.

Posted

I just upgraded to 5.2.9 from 5.2.8 and I have a problem with admin login also.

My problem is after I login to admin it would kick my out while I am working.

It usually is when I adding or editing products. But I also notice images not showing up too.

 

it doesn't matter what browser i use.

Posted

Ok, the browser is not POSTing the form.

 

If you wish to not let us know of a site where this can be experienced, we understand. But it would help.

 

There is no code difference in the HTML for the login page between CC528 and CC529.


@tkdrcb, welcome to the forums!

 

What browser are you using? If it's Internet Explorer 11, we have some not so good news. We have yet to figure out why IE11 behaves as badly as it does.

Posted

In the file /classes/session.class.php, near line 602, make this edit if necessary:

Was:
if($this->_http_user_agent()=='IEX') {
Now:
if($this->_http_user_agent() !== 'IEX') {

Please let us know if this makes any difference.

Posted

@tkdrcb, for every page request, I get a different cookie. And I get two cookies - they are the same name and value, but one says HttpOnly and the other says httponly. Note the lettercase difference.

 

The lowercase is from CubeCart, the uppercase is probably from the PHP.INI file. I do not know the consequences of browser behavior when receiving two nearly identical cookies.

 

Anyway, getting a new cookie for each page request, even though my browser is sending the current cookie back, is a problem.

 

I wonder what would happen if you replaced JUST the file /classes/session.class.php with the CC528 version.

 

Please know that significant code changes were made in this file to solve an identified security issue.

Posted

Just FYI -

This was happening in 5.2.7 this morning BEFORE I upgraded to 5.2.9 to see if that would help.

5.2.7 was working fine in all browsers until I patched OpenSSL late yesterday and updated php to the latest Atomic version.

 

Don't know if it could be the OpenSSL fix or a problem with the new php version.

 

CC doesn't like something that changed between the two.

Posted

Don't think so.  All other logins work on all browsers.  WordPress, Webassist, my own authentication system, everything on my server except CubeCart works fine on all browsers and all platforms.   Plus, this issue is only on IE, Safari and Opera - win & mac and only on CubeCart.

 

Even if it were a server setting, wouldn't it affect all browsers and not just these three?

Posted

Here's an interesting tidbit I just noticed -

If you put in the CORRECT user and password, it does virtually nothing.  No error message, just loops back to the login page with empty input fields.

 

If you put in an INCORRECT user or password, it submits and gives you the correct error message back on the login page.

 

It appears that in these particular browsers, CC is authenticating the login and immediately logging out or somehow killing the session, so it defaults back to the login page.

 

And again, ONLY in these 3 browsers.

Posted

Then we can assume all browsers are actually POSTing the form data, which is not what we concluded in post #3.

 

For a brief moment, please disable CubeCart's use of SSL mode in the admin Store Settings screen.

 

If these browsers still can't get past the login, then I would have to conclude it is something other than the OpenSSL having been patched.

 

Look in admin, Server Logs, Access logs, etc to see if the failed login attempts are recorded.

 

 

Please use a utility such as phpMyAdmin to view your database directly. Look in the CubeCart_blocker table. Remove all records this table may contain.

Posted
please disable CubeCart's use of SSL mode in the admin Store Settings screen.

Didn't help

 

Look in admin, Server Logs, Access logs, etc to see if the failed login attempts are recorded.

No, only the successful logins from Chrome and Firefox.  It does not register any login failures from the affected browsers.

 

Look in the CubeCart_blocker table. Remove all records this table may contain.

That table was completely empty.

 

Another interesting discovery -

I went in to the SSL tab in the store admin using Firefox and added the domain in the cookie field as per the example (using the real domain) and then logged out of that browser.  Not only did it have no effect on IE, it caused Firefox to start behaving the same way.

 

I had to go into Chrome and dump that setting and then dumped all the cookies in Firefox to be able to log in with that browser again. 

 

Still no joy on IE, Safari and Opera.

Posted

Has anyone else been able to duplicate this issue?

 

Are the CC devs sure that the store isn't dependent upon the Heartbeat handshake for authentication in some browsers?

Now that it is removed as part of the OpenSSL patch, that is about the only thing that has changed assuming the minor update of php from the Atomic Repo didn't do something.  I am highly doubtful of that.

Posted

Assuming there is nothing weird in the encoded files, CubeCart will only operate differently in these situations:

 

* You have enabled the mobile skin, and the browser sends a user-agent string that matches a regex looking for mobile user-agent strings.

* You use a version of Internet Explorer that has the word 'Trident' in its user-agent string.

 

The first case will send back the storefront mobile skin - does not affect admin.

The second case will not issue a cookie to Internet Explorer - which sounds weird.

 

To really see what is happening with your site, one would need to insert some tracking diagnostic code to find where CubeCart is deciding to send back the log-in page. Devellion would be the best people to do that, and you will need to use one of your support credits to get that research process started. If it's a definite bug with CubeCart, the support credit will be returned.

Posted

It appears I have solved the issue. The server's clock was jumping time for some strange reason after the yum update.  I did check it and reset it a couple of times and it would go hours off for unknown reasons just hours later.

I did a server re-configure and reset the system and hardware clocks and it solved the issue.

 

Now we wait and see if the system time stays stable.  I have it sync'd to an ntp (pool.ntp.org) so that with the re-configure should do it (I hope). 

 

The moral of the story is that some browsers will not validate the login if the server system clock is not accurate.  I assume it is because the cookie shows as expired as soon as it is written so it jumps you right back to the login page.

 

Funny that Firefox and Chrome don't seem to care.

Posted

Just to follow up on this.

We had the same issue with the NTP server on our Linux/CentOS/Plesk server after the OpenSSL patches applied on Tues. a.m.. The server timestamps would be off by an hour (CDT vs EDT). First fix, sync to nasa.gov's NTP would then put it two hours in the future (!).  We finally got this fixed and I think any web server running CentOS6.5/PHP5.4/ might have this issue. I had no login issue with IE11/Win764, but I did on the Plesk admin panel, when I tried to change anything it would kick me back out to login, which is how I suspected the timestamp issue. A simple shtml or php script to echo current server time will show this issue. We had server set to NY time for Apache, Plesk, and php, but the NTP would not sync to external time server.

 

Authorize.net will also dump order attempts if system time is too far out of sync with realtime.

 

If you run a daily logwatch for your server, it ,may appear in the log as an error, "NTP in use."

 

We fixed this on Thursday, and seems to be stable so far.

 

Cookies won't work if they are one to two hours in the future!

Posted

I think you are correct as we are running CentOS 6.5 and php 5.4.

 

I do run logwatch and didn't get any NTP notifications, but I did have that "2 hours in the future" time bounce issue that seems to be resolved with a reconfigure all command on psa and having the server sync to pool.ntp.org.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...