Post by taggsladder » Wed Jan 15, 2020 9:23 pm

Hello

Searched alot on this and noticed many having issues related to this but not my actual problem.

I have an Opencart 2.3.0.2 on Apache 2.4 / PHP 7.2 server with TLS enabled and forced.

The key here is that the installation have been working flawlessly for over a year with no modifications at all during this time.

But recently I get the dredded "Warning: You do not have permission to access the API!" in different places related to adding/modifying orders in admin section.

This is not related to my IP not added to api, I know how this work.

The thing is that if I spam the browsers refresh button it eventually works, like the error comes roughly 1 out of 3 refresh, but it differs.

I have located the line in different files in "catalog/controller/api" that couses the problem and it is:

Code: Select all

if (!isset($this->session->data['api_id'])) {
	$json['error'] = $this->language->get('error_permission');

If I change it to the below the error goes away, but obviously I don't want to do that.

Code: Select all

if (false) {
	$json['error'] = $this->language->get('error_permission');

Since the problem comes and goes my conslusion is that this must be a server side error, but I am not in full charge of the servers.
No information from the host provider has noticed me of any server change and the apache/php versions have been the same all time.

Any thoughts on how to troubleshoot this?

Newbie

Posts

Joined
Tue Sep 30, 2014 10:20 pm

Post by opencartmart » Thu Jan 16, 2020 3:47 pm

You may get the same error if the API token is expired. Since it is not IP related, it appears to be a token expiration thing.
By default, the lifetime of a token is 1 hour, if you want to extend it, you can modify the value in the controller/startup/session.php file. The query you have to modify:

Code: Select all

$this->db->query("DELETE FROM `" . DB_PREFIX . "api_session` WHERE TIMESTAMPADD(HOUR, 1, date_modified) < NOW()");
Look at the number just after `HOUR`

XForm - Opencart Form Builder
Xshippingpro - An advanced Shipping Module
Need Professional support? Skype: opencartmart


Active Member

Posts

Joined
Wed Oct 02, 2013 3:59 am

Post by taggsladder » Thu Jan 16, 2020 6:09 pm

opencartmart wrote:
Thu Jan 16, 2020 3:47 pm
You may get the same error if the API token is expired. Since it is not IP related, it appears to be a token expiration thing.
By default, the lifetime of a token is 1 hour, if you want to extend it, you can modify the value in the controller/startup/session.php file. The query you have to modify:

Code: Select all

$this->db->query("DELETE FROM `" . DB_PREFIX . "api_session` WHERE TIMESTAMPADD(HOUR, 1, date_modified) < NOW()");
Look at the number just after `HOUR`
I don't think this is it since the problem occurs immediately after login.

Newbie

Posts

Joined
Tue Sep 30, 2014 10:20 pm

Post by opencartmart » Thu Jan 16, 2020 8:37 pm

taggsladder wrote:
Thu Jan 16, 2020 6:09 pm
I don't think this is it since the problem occurs immediately after login.
Then, what could be the reason? Don't forget to enlighten us if you ever find it.

By the way, it is worth a try removing that query.

XForm - Opencart Form Builder
Xshippingpro - An advanced Shipping Module
Need Professional support? Skype: opencartmart


Active Member

Posts

Joined
Wed Oct 02, 2013 3:59 am

Post by taggsladder » Thu Jan 16, 2020 10:26 pm

opencartmart wrote:
Thu Jan 16, 2020 8:37 pm
taggsladder wrote:
Thu Jan 16, 2020 6:09 pm
I don't think this is it since the problem occurs immediately after login.
Then, what could be the reason? Don't forget to enlighten us if you ever find it.

By the way, it is worth a try removing that query.
I am trying to figure that out. Yes I will do that.

Commenting out that line did not fix the issue.

---

I don't have any real understand how the sessions work. Are they stored in cookie?

Thought it was a cookie problem first but tried 3 different computers running different OS and browsers.

---

I have found some kind of pattern now to get the error to not come up. Tried this over 20 times with same result no deviation.

If I wait > 35 seconds (approx) between refreshing this page the error never comes!
Sales > Orders > Add new (top right corner)

But If I refresh the page sooner the error may come or may not come. Usually comes more often than not.
i. e. if I just refresh the page every second sometimes error comes sometimes not, seems random to me.


For clarity regarding the example page above "Add order", when the error shows the "currency" dropdown list is marked red.

---

Just playing around now:

In admin panel I go and delete all sessions.
System > Users > API > Default > Session tab

Logout and login again.

Go directly to session list again. It is still empty.
System > Users > API > Default > Session tab

When I goto page below new entry is added in sessions tab every time I refresh the page. New entry both on error appearing and not.
Sales > Orders > Add new (top right corner)

This is correct behavior?

Newbie

Posts

Joined
Tue Sep 30, 2014 10:20 pm

Post by opencartmart » Fri Jan 17, 2020 1:13 am

taggsladder wrote:
Thu Jan 16, 2020 10:26 pm
When I goto page below new entry is added in sessions tab every time I refresh the page.
This is correct behavior?
Yes it is correct behavior in OC 2.3.x
taggsladder wrote:
Thu Jan 16, 2020 10:26 pm
New entry both on error appearing and not.
Sales > Orders > Add new (top right corner)
This is correct behavior?
Nope, it should not show any error unless your IP address changes too frequently.

By the way, controller/startup/session.php is the file where API session is generated. So you can debug that file and it is a small file, fortunately.

XForm - Opencart Form Builder
Xshippingpro - An advanced Shipping Module
Need Professional support? Skype: opencartmart


Active Member

Posts

Joined
Wed Oct 02, 2013 3:59 am

Post by thekrotek » Fri Jan 17, 2020 5:10 am

OC 2.3 is well know for its broken API connections. You can either disable API checks completely with Disable API Checks extension or downgrade to OC 2.2, which doesn't have such issues. Actually, any other OC version doesn't have such issues. At least on the regular basis.

Professional OpenCart extensions, support and custom work.
Contact me via email or Skype by support@thekrotek.com


User avatar
Expert Member

Posts

Joined
Sun Jul 03, 2016 12:24 am


Post by pcanka2019 » Mon Jan 20, 2020 6:10 pm

Have the same problem - it has worked fine until appr. 1 month ago when the server host upgraded from php 7.1 to 7.2 (maybe they have done something else as well...). I have to refresh the module changer several times to get it to work (update the order and API message gone) . This will only work with IE not Chrome nor Firefox.

I don´t understand the suggestion to install the "Disable API Checks" when it states "By removing API security checks you can make your OpenCart API vulnerable!"

Newbie

Posts

Joined
Wed Feb 27, 2019 11:59 pm

Post by taggsladder » Mon Jan 20, 2020 7:12 pm

pcanka2019 wrote:
Mon Jan 20, 2020 6:10 pm
Have the same problem - it has worked fine until appr. 1 month ago when the server host upgraded from php 7.1 to 7.2 (maybe they have done something else as well...). I have to refresh the module changer several times to get it to work (update the order and API message gone) . This will only work with IE not Chrome nor Firefox.

I don´t understand the suggestion to install the "Disable API Checks" when it states "By removing API security checks you can make your OpenCart API vulnerable!"
OK, I have run it on PHP 7.2 over a year without a problem. Only issue with PHP 7.2 and OC 2.3.0.2 is mcrypt depriciated in PHP 7.2 I replaced it with openssl but this should not be relevant to this problem though.

For me I can refresh and get rid of the error in both Chrome and Safari on Mac OS. Not tried IE or Firefox. Seems unrelated to browser.

No I am not keen on that hack either.


Funny I choose the latest release of OC 2 thinking it should be the most stable and refined...

Newbie

Posts

Joined
Tue Sep 30, 2014 10:20 pm

Post by straightlight » Mon Jan 20, 2020 9:56 pm

taggsladder wrote:
Mon Jan 20, 2020 7:12 pm
pcanka2019 wrote:
Mon Jan 20, 2020 6:10 pm
Have the same problem - it has worked fine until appr. 1 month ago when the server host upgraded from php 7.1 to 7.2 (maybe they have done something else as well...). I have to refresh the module changer several times to get it to work (update the order and API message gone) . This will only work with IE not Chrome nor Firefox.

I don´t understand the suggestion to install the "Disable API Checks" when it states "By removing API security checks you can make your OpenCart API vulnerable!"
OK, I have run it on PHP 7.2 over a year without a problem. Only issue with PHP 7.2 and OC 2.3.0.2 is mcrypt depriciated in PHP 7.2 I replaced it with openssl but this should not be relevant to this problem though.

For me I can refresh and get rid of the error in both Chrome and Safari on Mac OS. Not tried IE or Firefox. Seems unrelated to browser.

No I am not keen on that hack either.


Funny I choose the latest release of OC 2 thinking it should be the most stable and refined...
Unbelievable, not a single post from supporters about requesting the OP to post the error / server access logs. Just a bunch of guess response without gathering the facts from a server whenever it comes to technical issues being reported.

@taggslader: Can you please post your error / server access logs as per the forum rules?

As for the OpenSSL, there has been updated solutions regarding the system/library/encryption.php file since v2.3.0.2's release. The internal API's backward compatibility does rely on sessions where sessions also relies on SSL functions to operate properly. Which is why, it is recommended to use SSL with Opencart.

Also take note that v2.3.0.2 contains some bugs regarding the order fraud extensions which may require for you to patch by using the official release.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by taggsladder » Tue Jan 21, 2020 1:45 am

straightlight wrote:
Mon Jan 20, 2020 9:56 pm
Unbelievable, not a single post from supporters about requesting the OP to post the error / server access logs. Just a bunch of guess response without gathering the facts from a server whenever it comes to technical issues being reported.

@taggslader: Can you please post your error / server access logs as per the forum rules?
Apache error log did not contain anything related to this. First thing I checked.

To be sure.
1. Deleted old error log.
2. Went into admin panel and made sure this API error got displayed a couple of times.
3. Looked into error log = empty.
4. Forced a PHP error by writing random bad code.
5. Looked into error log again, above forced error was logged.

I set "php_value error_reporting -1" in .htaccess, from my understanding this should log all types of errors.

My conclusion = Error logging works but this problem does not seem to log an error in error.log.

Regarding access.log I have not permission by the hosting provider to look at this. I have e-mailed them and asked about this. Will let you know.


straightlight wrote:
Mon Jan 20, 2020 9:56 pm
As for the OpenSSL, there has been updated solutions regarding the system/library/encryption.php file since v2.3.0.2's release. The internal API's backward compatibility does rely on sessions where sessions also relies on SSL functions to operate properly.
When I mentioned openssl I meant I just replaced the deprecated mcrypt_encrypt with openssl_encrypt function in system/library/encryption.php.

In other words:
Replaced this line:

Code: Select all

return strtr(base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, hash('sha256', $this->key, true), $value, MCRYPT_MODE_ECB)), '+/=', '-_,');
With this line:

Code: Select all

return base64_encode(openssl_encrypt($value, 'AES-256-CBC', hash('sha256', $this->key, true), 0, substr(hash('sha256', $this->key, true), 16, 16)));
Which I bieleve should do the job equally.


straightlight wrote:
Mon Jan 20, 2020 9:56 pm
Which is why, it is recommended to use SSL with Opencart.
As I wrote in my first post "I have an Opencart 2.3.0.2 on Apache 2.4 / PHP 7.2 server with TLS enabled and forced.".

What I meant by this is that TLS (SSL) is enabled on hosting provider and "forced" in my hosting providers settings page to redirect all http trafic to https.

Also in OC config.php both "define('HTTP_SERVER'" and "define('HTTPS_SERVER'" has the https domain.

And of course in OC admin panel System > Settings > Server I have selected "yes" in "Use SSL" option.

straightlight wrote:
Mon Jan 20, 2020 9:56 pm
Also take note that v2.3.0.2 contains some bugs regarding the order fraud extensions which may require for you to patch by using the official release.
I do not use this extension but thank you.

Newbie

Posts

Joined
Tue Sep 30, 2014 10:20 pm

Post by straightlight » Tue Jan 21, 2020 7:00 am

taggsladder wrote:
Tue Jan 21, 2020 1:45 am
straightlight wrote:
Mon Jan 20, 2020 9:56 pm
Unbelievable, not a single post from supporters about requesting the OP to post the error / server access logs. Just a bunch of guess response without gathering the facts from a server whenever it comes to technical issues being reported.

@taggslader: Can you please post your error / server access logs as per the forum rules?
Apache error log did not contain anything related to this. First thing I checked.

To be sure.
1. Deleted old error log.
2. Went into admin panel and made sure this API error got displayed a couple of times.
3. Looked into error log = empty.
4. Forced a PHP error by writing random bad code.
5. Looked into error log again, above forced error was logged.

I set "php_value error_reporting -1" in .htaccess, from my understanding this should log all types of errors.

My conclusion = Error logging works but this problem does not seem to log an error in error.log.

Regarding access.log I have not permission by the hosting provider to look at this. I have e-mailed them and asked about this. Will let you know.


straightlight wrote:
Mon Jan 20, 2020 9:56 pm
As for the OpenSSL, there has been updated solutions regarding the system/library/encryption.php file since v2.3.0.2's release. The internal API's backward compatibility does rely on sessions where sessions also relies on SSL functions to operate properly.
When I mentioned openssl I meant I just replaced the deprecated mcrypt_encrypt with openssl_encrypt function in system/library/encryption.php.

In other words:
Replaced this line:

Code: Select all

return strtr(base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, hash('sha256', $this->key, true), $value, MCRYPT_MODE_ECB)), '+/=', '-_,');
With this line:

Code: Select all

return base64_encode(openssl_encrypt($value, 'AES-256-CBC', hash('sha256', $this->key, true), 0, substr(hash('sha256', $this->key, true), 16, 16)));
Which I bieleve should do the job equally.


straightlight wrote:
Mon Jan 20, 2020 9:56 pm
Which is why, it is recommended to use SSL with Opencart.
As I wrote in my first post "I have an Opencart 2.3.0.2 on Apache 2.4 / PHP 7.2 server with TLS enabled and forced.".

What I meant by this is that TLS (SSL) is enabled on hosting provider and "forced" in my hosting providers settings page to redirect all http trafic to https.

Also in OC config.php both "define('HTTP_SERVER'" and "define('HTTPS_SERVER'" has the https domain.

And of course in OC admin panel System > Settings > Server I have selected "yes" in "Use SSL" option.

straightlight wrote:
Mon Jan 20, 2020 9:56 pm
Also take note that v2.3.0.2 contains some bugs regarding the order fraud extensions which may require for you to patch by using the official release.
I do not use this extension but thank you.
php_value error_reporting -1
Then your conclusion based on this analysis remains incomplete since your host restricts you of access to view your domain error logs aside from the set_error_handler reported errors from PHP. Contacting your host would be the right initiative.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by taggsladder » Thu Jan 23, 2020 11:44 pm

straightlight wrote:
Tue Jan 21, 2020 7:00 am
Then your conclusion based on this analysis remains incomplete since your host restricts you of access to view your domain error logs aside from the set_error_handler reported errors from PHP. Contacting your host would be the right initiative.
My host has now sent me the logs (apache error and access log) for a test period time of 30 minutes (2020-01-22 10:30 - 2020-01-22 11:00) where I reproduced the problem in the sequence below.

1. Goto admin and login.
2. Go to Sales > Orders > Add new (top right corner)
3. I then refreshed this page 8 times with the results below.

First load: No error
Refresh 1: Error appeared
Refresh 2: No error
Refresh 3: No error
Refresh 4: No error
Refresh 5: No error
Refresh 6: No error
Refresh 7: No error
Refresh 8: Error appeared

4. I logged out of admin panel.

The error log was empty.
The access log is attached.

The logs are from a server where only I have permission to access so all request are from me, this server is a duplicate of my production server. Both servers share the same problem, but they are also on the same host with same setup. Though on a different domains and different TLS certs.

I cannot see anything obvious in access log other than that the token in url is the same for every request other than "?route=api/currency" wich have a new token everytime. This is correct behavior? Cannot see any pattern though that relates this to when the error occurs and not.

Next thing would maybe be to duplicate the OC installation on a local server but I don't feel like that at the moment..

Also tried upgrading to PHP 7.4, made no difference.

Newbie

Posts

Joined
Tue Sep 30, 2014 10:20 pm

Post by pcanka2019 » Fri Jan 24, 2020 4:16 pm

Followed advice:

Replaced this line:
Code: Select all

return strtr(base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, hash('sha256', $this->key, true), $value, MCRYPT_MODE_ECB)), '+/=', '-_,');
With this line:
Code: Select all

return base64_encode(openssl_encrypt($value, 'AES-256-CBC', hash('sha256', $this->key, true), 0, substr(hash('sha256', $this->key, true), 16, 16)));


In chrome browser: After this I could update an order 1 time without API error meassage, after that the API error is back (static). So I have to use IE browser where it works after refreshing the module changer several times.

Question: is it necessery to update the public function decrypt in some way as well?

public function decrypt($value) {
return trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, hash('sha256', $this->key, true), base64_decode(strtr($value, '-_,', '+/=')), MCRYPT_MODE_ECB));

Sorry for not being able to add any OC log - when trying to check it - it freezes the browser (IE and Chrome) .

Newbie

Posts

Joined
Wed Feb 27, 2019 11:59 pm

Post by xxvirusxx » Fri Jan 24, 2020 4:49 pm

Replace all content with this

Code: Select all

<?php
final class Encryption {
	public function encrypt($key, $value) {
		return strtr(base64_encode(openssl_encrypt($value, 'aes-128-cbc', hash('sha256', $key, true))), '+/=', '-_,');
	}
	public function decrypt($key, $value) {
		return trim(openssl_decrypt(base64_decode(strtr($value, '-_,', '+/=')), 'aes-128-cbc', hash('sha256', $key, true)));
	}
}

Upgrade Service | OC 2.3.0.2 PHP 8 | My Custom OC 3.0.3.8 | Buy me a beer


User avatar
Expert Member

Posts

Joined
Tue Jul 17, 2012 10:35 pm
Location - România

Post by taggsladder » Fri Jan 24, 2020 6:07 pm

I forgot to mention in my prev post that I of course also replaced "mcrypt_decrypt" with "openssl_decrypt" similiar as post above.


I done some more testing and the behavior changes is Chrome (79.0.3945.88) when I have developer tools open.

The settings in developer tools is the default. I have no deep understanding on how developer tools changes browser behavior but looking in settings i see for example "disable cache (while devtools is open)" wich is enabled.

If I have developer tools open the error appears much more frequent. I cannot just spam refresh like if devtools was closed.

When devtools is open it is more like if it relates to the time since last time error did not appear. Like it resets some timer when error does not appear and no matter how hard I smash refresh some amount of time needs to pass until next time error goes away and this repeats.

When devtools is closed I can just spam refresh button like every second and some times error appears sometimes it does not except as described in prev post if I wait > 35s between every refresh the error never appears.

Don't usually fuck with that shit but I tried Microsoft Edge now also and It seems to behave more like when Chrome when devtools is open.

Newbie

Posts

Joined
Tue Sep 30, 2014 10:20 pm

Post by pcanka2019 » Tue Feb 11, 2020 8:38 pm

Updated the "encryption.php" file with the code from "xxvirusxx ", but no effect. Still can´t use Chrome only IExplorer (with random API messages).

Newbie

Posts

Joined
Wed Feb 27, 2019 11:59 pm

Post by straightlight » Wed Feb 12, 2020 6:42 am

Use the one from AddCreative and see if that resolves the issue: viewtopic.php?f=198&t=204707&p=737628#p737628

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by pcanka2019 » Mon Feb 17, 2020 5:44 pm

It says "There are a few errors in the code posted. " ... and I am a novice so I don´t know how to writ the code.

Newbie

Posts

Joined
Wed Feb 27, 2019 11:59 pm

Post by straightlight » Mon Feb 17, 2020 10:35 pm

What errors? More information is needed.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON
Who is online

Users browsing this forum: No registered users and 162 guests