Jump to content

keat

Member
  • Posts

    1,614
  • Joined

  • Last visited

  • Days Won

    27

Everything posted by keat

  1. The reply from Cpanel indicates that this may require further config changes at server level. Thank you for the additional information. The behavior you noticed is by design. The "/usr/local/cpanel/scripts/clean_user_php_sessions" script will only recognize the global "session.gc_maxlifetime" PHP configuration value configured for each version of PHP. If a custom value for "session.gc_maxlifetime" is preferred for an individual account, then the workaround is to also configure a custom "session.save_path" value for the account. This will allow PHP to handle the session cleanup, as opposed to the "/usr/local/cpanel/scripts/clean_user_php_sessions" script. In other words, the server by default will probably have sessions.gc_maxlifetime configured for 1440 seconds as it's master value. The cleanup script looks at this mater value for it's basis of when to perform the job. Changing the master value on your domain will have no effect, as it's still looking at the master value on the server. As my server is our own, I can change this master value server wide.
  2. Further update, which is now pointing more towards a PHP issue, (I'm not sure if this is just Cpanel.) It appears that local garbage collection settings via PHP ini_set are ignored and the script runs listening to the master value only. The "/usr/local/cpanel/scripts/clean_user_php_sessions" script will only recognize the global "session.gc_maxlifetime" PHP configuration value configured for each version of PHP. If a custom value for "session.gc_maxlifetime" is preferred for an individual account, then the workaround is to also configure a custom "session.save_path" value for the account. This will allow PHP to handle the session cleanup, as opposed to the "/usr/local/cpanel/scripts/clean_user_php_sessions" script.
  3. keat

    PayPal Issues

    I updated to 1.0.8 the other day also. I'm not seeing any issues, I note your post was 19 hours old, so I checked back to yesterday and don't see any issues their either.
  4. Both Al and myself are now wondering if a script on another domain could affect this. eg, sessions are stored on the server in a central location, possibly along with other sessions from other domains (as is the case for certain on my server). What happens if a script triggers the garbage clean, how would it identify which sessions to clean and which to remove. So changing the setting on your domain, may not have any impact if your sessions are stored along with everyone elses. something else on the server could send the instruction to perform a clean up. I have my own server, so changing the setting was a global server wide setting for me, which could explain why mine now works. I'm certainly no expert in this area, so it might be worth watching the Cpanel thread (posted above) and see what they have to say. see Als comments regarding domain x and Y Hopefully we'll have an answer in a few days.
  5. I found this in debug. curl_exec() has been disabled for security reasons - Unable to reach reCAPCHA server I tested disabling some PHP functions early this morning, and then re-enabled them, I suspect something has been left behind. although i've no idea why it still works on the test site, maybe inheritance of php
  6. I'm using V1 of recapture, but it appears to have stopped working. I see a message saying 'The verification codes were incorrect. Please verify that you are human.' I know recapture works, as I have it running on a test site, but for some reason it's not working on my main site. any ideas ?
  7. Sessions.gc_maxlifetime is garbage cleanup. If a session has been left open and untouched for 1440 seconds (24 minutes) it's deemed by PHP to be garbage and is then deleted. However, 24 minutes is not hard and fast as the deletion is done by another process which runs as a schedule. In my case 24 minutes, turns out to be about 40. Cubecart appears to be telling PHP to use 604800 (7 days), but for whatever reason, PHP is ignoring this and using the master setting of 24 minutes. This also has me wondering if other local settings are being ignored. I have a thread running on the Cpanel forum, which may or may not turn in to a support ticket. https://forums.cpanel.net/threads/session-gc_maxlifetime.606031/
  8. Something makes me think if sessions.class.php isn't handling this then maybe .htaccess won't either, but it might be worth investigating. More info https://stackoverflow.com/questions/10704370/php-session-timeout-htaccess-file
  9. If it is related to gc maxlifetime, then the setting is called session.gc_maxlifetime, which is a setting in the PHP config on the server, you may not have access to this, as it has to be performed at OS level. Maybe your hosting provider might be willing to change this on your hosting plan. If you look in cart PHP info, you should find 2 settings. One will be 604800 (7 days) the other 1440 (24 minutes) It seems for what ever reason, the master setting of 24 minutes is taking precidence over the local setting of 7 days. Maybe this is also occuring with other local vs master settings, and quite possibly something which has come about with a PHP update. Something we discovered last week. I'm not sure of the long term fix, Al would have a better understanding of this. It seems that it may be possble to set this in .htaccess https://stackoverflow.com/questions/6253498/declaring-session-max-life-time-in-htaccess However, I did mine at OS level, so never tried with .htaccess
  10. We've used SecPay, which became PayPoint and now Pay360. Since Crapita took over, the support has gone real down hill, to the point that i've had enough of being given the run around and now cosidering switching to Worldpay. Does anyne use Worldpay, and how do you find them.
  11. It's looking like this is related to PHP server setting session.gc_maxlifetime Both Al and myself have performed numerous test orders on a spare domain and can recreate or fix the issue with a PHP config change. It's also looking like it's related to a CSRF error seen by others. sessions.class.php should be handling this, hopefully, Al will figure out why it's not, or maybe why my server is ignoring it, as not everyone will have access to the PHP config.
  12. Sorry, I ought to have updated. I spotted those links last week and swapped the files for the minified ones. Page insights isn't all that accurate though. I can have a green card on one run and a yellow one the next, now fluctuating anywhere between about 88 (green) and 80 (amber) Seositecheckup.com gives me a decent score of 95 though.
  13. OK, this looks like its on your own site. I think you need https at least for this. As per HarrisOrganic says If you go to manage extenstions, find card capture, and then allowed zones, you'll need to add the zones which are allowed to post card details. Personally, I'd avoid this plugin and use something like PayPal, as you're probably contravening all PCI DSS rules hosting the card gateway yourself. Experience a security breach and a whole can of worms could open up for you. Just my opinion.
  14. where is he inputting his card details, directly on your site or via a host.
  15. I've now recreated this issue on a stock 6.1.8 site. Mican Skin, Print Order Form and All in one Shipping, everything else is stock.
  16. Al has also managed to recreate this on at least two of my web sites, so hopefully, we'll find a resolution. Both web sites are on different servers I might add.
  17. keat

    howdy

    In the database, have a look at the category index table. If you imported your parts, they may well not be linked to a category.
  18. Did you check that the file sources/maintenance/indexbackup.inc.php does exist.
  19. PayPal was acting up last week, maybe it is again today. Transactions were taking up to two hours to show up in the PayPal web page. If you can, then switch to the old classic view, as I found the transactions would display in there, but not in the new look.
  20. I've sucessfully recreated this three times this afternoon. Using Firefox and Mican Skin (we've seen this on our foundation skin site also) Add items to your basket without logging in, when the basket has about 4 or 5 items, proceed through the checkout process, choosing a shipping method (if applicable). When prompted to create an account or log in, log in with your test account. Without proceeding any further, leave the browser open. Do not continue, just let the browser sit idle. After a period of time (iv'e left 40 minutes), come back click the continue button. Cart is logged with null items. I'm now attempting to recreate using Chrome browser.
  21. And now another one. The customer is using Firefox. He seems to think that he placed items in his basket, clicked the continue button, and was taken to an orde complete page. He says that no gateway was selected, as if it skipped the gateway stage all together. 170717.csv
  22. Going back to my CSV file, not how this customer is using firefix and then possible an Ipad. I looked inside Cubecart_access_logs and found the transaction, I assume this is the correct one, as I can see the next customer shortly afterwards which tallies with the orders for that day. Cubecart_access_logs denotes IEX as the user agent.. I assume Internet Explorer. Could this have anything to do with it ??
  23. I've identified this customer and then searched the saved cart table for anything with his customer ID. I find 1 blob file with just a single item, iv'e no idea if this is a recent saved cart or an old one, but certainly no where near the amount of items he's saying that he'd placed.
  24. I've had a very irate customer call today that a basket with over 250 items which he's been building up over a period of two weeks has all gone to zero. Of course, building a basket for two weeks isn't good practice, but how do I explain this to him, when he does this with his other service providers. Whilst on this occasion, we didn't see the order at our end, I can't help thinking that it's related. from the gist of the conversation, I guess his basket zero'd out at his end and he spotted it before committing the order. @Al Brookbanks, could you or your team take a look at my CSV from 2 days ago please, we have to get to the bottom of this.
×
×
  • Create New...