Jump to content

jasehead

Member
 View Profile  See their activity

  • Posts

    213

  • Joined

  • Last visited

  • Days Won

    1

 Content Type 

Everything posted by jasehead

  1. jasehead
    There are no indexes or keys applied to the table - it's just simple.
  2. jasehead
    I've tracked the .htaccess with the 403 redirect to the web root (tested .htaccess files in web root, store folder and admin folder). ErrorDocument 403 https://www.mysite.com.au/store/ Saving changes to the store settings is causing a 403 error. Should I be looking at file permissions or contacting my host about mod_security rules? Can't add a column to the CubeCart_config table - the table cannot be edited because of the duplicated rows. I would expect I'd probably have to export the database, edit the text file and import it back. I think the duplicate rows crept in during multiple CubeCart upgrades over the years.
  3. jasehead
    I had a look at decoding the config with Base64, making changes and pasting into phpMyAdmin - but the config table has config, Free_Shipping and Print_Order_Form twice so I can't assign a unique key to be able to edit the config. I guess I could write a replace in SQL but I'm starting to feel like I'm hacking at this problem with an axe.
  4. jasehead
    Could an apostrophe in the settings be a new issue? It wasn't previously, but checking the staff access log the last "Settings updated" entry was 11 days ago, and that would have been updating 2018 to 2019 in the Search Engine Settings > Meta Keywords. In Settings, we have apostrophes in the store name, meta description and copyright. Unfortunately, I can't remove the apostrophes to test this theory because the store settings won't save.
  5. jasehead
    The admin file and folder are both correct in global.inc.php - I can log into admin OK, view and edit orders, add products, clear cache etc. But trying to save changes to store settings is the problem. I did try commenting out 404 and 403 redirects in .htaccess at the web root and also the store folder but still had the problem. In Admin, .htaccess says: ErrorDocument 404 "<html></html> So I tried commenting that out too - no change.
  6. jasehead
    Replacing the Admin folder didn't solve the problem.
  7. jasehead
    I'm using cc6.1.14 and trying to make a store settings change in admin, but when I try to save it redirects to the home page of the store instead (not admin). I've tried disabling any 404 or 403 redirects in .htaccess but no luck. I did have a look at the store config settings in phpMyAdmin to see if I could make my small change there but I think the config is locked up with binhex. I'm going to try backing up my Admin folder and reinstalling a vanilla version, but if anyone has any ideas on where to look for what is causing this problem let me know.
  8. jasehead
    After searching through code changes and not finding anything: I renamed my custom skin folder by adding a few characters (BOB11) Made a copy of the Foundation folder and renamed it to my original custom skin name (BOB) Replaced the config file in my new skin (BOB) with my old custom skin config (BOB11) Uploaded the new skin (BOB) to my site - so a fresh Foundation skin with my old config After that, I copied back the images, js and css folders - no issues with the site. Then I copied back any changed template files, two or three at a time. Each time I used Admin/Maintenance to clear the cache in Cubecart, then tested on Chrome, Firefox and Safari (clearing browser caches and reloading the page from source). I performed more than 30 tests on multiple browsers before all files were back and couldn't find any problem - a few blank screens at the gateway stage but that seemed to resolve itself after a while. So maybe there was some issue with the original files (done as an upgrade using the setup folder). A fresh upload of the Foundation skin and then adding back the modified files and cleaning the cache seems to have fixed my problem - BTW very similar to this one: https://forums.cubecart.com/topic/52443-register-and-checkout-not-working/
  9. jasehead
    This is happening to me too on 6.1.14 - when a guest customer completes their address details, the Secure Checkout button won't proceed. Also, when a guest tries to register, the Register button won't work. I've tested this with reCAPTCHA off and also v2. I have a heavily modded checkout, but I haven't touched the registration page. I'm thinking that if the registration page is having the same problem then there might be a shared script. I did try the vanilla Foundation skin and everything did work OK - registration was OK, checkout as guest was OK (both with reCAPTCHA v2) - so I'll be comparing my modded version to track down why.
  10. jasehead
    I've decided is to move the thumbnails from under the main image to under the Add to Basket button for medium-up, and under the image AND Add to Basket for small-only. I'll post the code when I'm happy with the layout - it looks good so far, except on small view when there are only a few thumbnails under the main image. What I would like to do for small-only is to have the thumbnails show in position depending on how many thumbnails there are. If there are 4 or less, then even on small view still show under the Add to Basket Button (as per medium-up). If there are more than 4 thumbnails then show under the main image AND Add to Basket (currently my default for small view). Is there any way I can do that?
  11. jasehead
    Looking at the code, I can see that the start of 2.cubecart.js sets the min and max height: if($('a.open-clearing img#img-preview').length) { $('a.open-clearing img#img-preview').load(function() { var ip = $('a.open-clearing img#img-preview'); var ip_height = ip.height(); var ip_width = ip.width(); var min_height = ip_width * 0.7; if(ip_height<min_height) { ip_height = min_height; } $('a.open-clearing img').css({'min-height':ip_height+'px', 'max-height': ip_height+'px'}); }); } So if the original/main image for a product is 407x407px, then any subsequent images swapped by hovering over thumbnails may also have their min and max height set to 407px. I'm attempting to swap the square image with a landscape (500W x 224H) - so the display size should be 407W x 182H The min_height would be ip_width (407) x 0.7 = 285, so if I'm reading the code right then my landscape image at 182H is less than 285H so the minimum height is then set to 407H and my landscape image is stretched to be a square.
  12. jasehead
    To stop the distortion... Without looking at any code, I'm thinking that CubeCart probably assumes that if an image is not square, then the height will be greater than the width (portrait view) so the height will be 100% (of the main image) and the width will be auto. The images to swap haven't been loaded yet so that's why a landscape image gets distorted into the size and shape of the main image (if you reload the page then the images are loaded from the cache so the size is already known). What I would like is for the largest dimension (height OR width) to be 100% and the other to be auto. The thumbnails are already generated on the page, so a height vs width ratio could be calculated from the thumbnail after the page has rendered but before the image swap occurs - the ratio would tell the image swap which value to set at 100% and which should be auto. This method would shrink larger images to the maximum height or width of the main image. --- It might also be possible to set the container for the main image to the maximum height of the other images for that product by estimating using the thumbnails. The thumbnails and other content wouldn't jump around, but there may be some white space if the main image is short and another image is quite long. --- Making all images the same 800 x 800px is the obvious advice (or same image dimensions per category or per single product), but a difficult request when you're looking at thousands of products over the years.
  13. jasehead
    Sorry, I avoid posting links to my own site for security. However, this page with vertical thumbnails shows the effect (store running 6.1.13). The main image is square and the subsequent landscape images are distorted to the square shape. http://www.cam-equestrian.com/product-rage/equestrian-sports-cams/sj4000-equestrian-camera-1080p-full-hd-dvr.html The distortion occurs on the initial page load. Reloading the page seems to change things - maximum display height of any image seems to become the minimum height of any cached landscape image for the product. In Safari I can "Reload Page from Origin" to avoid cached files (or Force Reload in Chrome) - in Firefox I think it's Ctrl + Shift + R (Windows, Linux) or Command + Shift + R (Mac). On my own site, I use a horizontal gallery of thumbnails.
  14. jasehead
    I have some products with as many as 10 thumbnail images - sometimes a mix of square, portrait or landscape. I often use one square image as the main image to keep the thumbnails on the category page the same size. In 6.0.12, hovering over thumbnails with different dimensions caused the size of the main image to change size and the thumbnail gallery would jump position. This was discussed here (Image Gallery Bounces #1449): https://github.com/cubecart/v6/issues/1449 However, in 6.1.14 if the main image is square then all portrait and landscape images are squished to be square as well. Because a number of changes were made as a result of #1449, is there a workaround that would adjust the image container to the largest height rather than squish all images to the dimensions of the main image? If the largest height can't be predicted, then maybe use the largest height found so once the thumbnail gallery jumps to a new position it won't jump back again.
  15. jasehead
    It's probably only affecting me because I'm hammering 6.1.14 trying to make it break before going live with an update, and so I found a way to break it. In my store, the document.write for the copyright year was responsible for the "2018" on a blank page when the security tokens didn't match and sanitise.class.php got upset. When I removed my javascript from the copyright, the security token mismatch returned a "page within a page" render of the home/main page - the page rendered twice. I tested other 6.1.14 Foundation stores (that were not mine) and they broke the same way. I've tested the 6.1.15 fix for "#1921 - Calms down CSRF token generation" and it seems to be the desired outcome. The security token issue happens less often and when it does, that doesn't cause the store to appear broken to the customer - the security token glitch happens less often and quieter, so the customer can continue shopping without noticing. The fix was for "CSRF token regeneration on each page load damages usability #1921", back button etc. so I don't think the security token issue was just affecting me. https://github.com/cubecart/v6/issues/1912 https://github.com/cubecart/v6/issues/1900
  16. jasehead
    Would this help with my security token issue? #1921 - Calms down CSRF token generation https://github.com/cubecart/v6/commit/79bf08ac1ec0cd9ca536d04c9b0f4d9964f3af63 In classes/sanitize.class.php around line 72: $GLOBALS['session']->getToken(true); self::_stopToken(); } //Make a new token // DELETE THIS LINE $GLOBALS['session']->getToken(true); // DELETE THIS LINE } } So I tried the edit and it seems to be a fix for my problem - I can't get the store to fall over now. It DID still manage to generate a couple of errors in the error log (one time the first token was different, another time it was missing) but this time the errors didn't spoil the customer experience. I got one notice from Safari saying the page was reloaded because of a problem, but that was acceptable. And in Chrome I had a suddenly empty basket, but that sorted itself by returning to the store.
  17. jasehead
    The Params of ?_g=ajaxadd had the token: 811754e0351d1b375363f980ce111513 The response payload can be the mini basket snippet of HTML (box.basket.php), but is more often the homepage with a "Security Alert: Possible Cross-Site Request Forgery (CSRF)" error. The response payload (correct html) is different to the generated page source of the "page within a page" (in Firefox Quantum, select all, right click, View Selected Source) - so the response payload is not showing what is rendered on the screen. I also see an error in developer tools that foundation.css could not be loaded. The response of the failed POST session_token was: 8b956a4057839992990c75e4a9f4166f (also the same token in the generated page source) IF I can make ?_g=ajaxadd appear in the waterfall WITH a token, THEN the main page appears broken and the tokens for ajaxadd and the response payload (or generated page source) are different - tested in all 3 browsers. --- I'm testing a stock item with only one copy available and no product options. In Firefox, if cubecart doesn't break it takes me to the product page with the error message "Sorry but that product is out of stock." If it does break then I see the homepage as "page within a page", and the mini basket appears briefly (like a normal Add to Basket event). In Safari, I have watched it stall on the "page within a page" render, or continue on to be replaced by "Your Shopping Basket" but with no error notices. In Chrome it's harder to tell because it often scrolls to the bottom of the "page within a page" which looks rendered OK - have to scroll to top to see the drama.
  18. jasehead
    [18-Apr-2018 17:48:35 UTC] PHP Warning: CubeCart Token: 4e525f3864a9f532c41e64c7cc0eb247 in /home2/myserver/public_html/cubecart/classes/session.class.php on line 256 [18-Apr-2018 17:48:35 UTC] PHP Warning: POSTed Token: 4e525f3864a9f532c41e64c7cc0eb247 in /home2/myserver/public_html/cubecart/classes/session.class.php on line 257 [18-Apr-2018 17:48:38 UTC] PHP Warning: CubeCart Token: 0f49326b2d1086695ad0b54f4fd0b11a in /home2/myserver/public_html/cubecart/classes/session.class.php on line 256 [18-Apr-2018 17:48:38 UTC] PHP Warning: POSTed Token: 0f49326b2d1086695ad0b54f4fd0b11a in /home2/myserver/public_html/cubecart/classes/session.class.php on line 257 [18-Apr-2018 17:48:40 UTC] PHP Warning: CubeCart Token: 3622c2819ff498ed5c72dc816d1644d4 in /home2/myserver/public_html/cubecart/classes/session.class.php on line 256 [18-Apr-2018 17:48:40 UTC] PHP Warning: POSTed Token: d560a6106068910c62413e50e96e4681 in /home2/myserver/public_html/cubecart/classes/session.class.php on line 257 [18-Apr-2018 17:48:40 UTC] PHP Warning: Invalid Security Token in /home2/myserver/public_html/cubecart/classes/sanitize.class.php on line 152 Tidied for readability. Vigorous use of the back button and Add to Basket click - took a few tries to get it to fall over but it's clear there's a token mismatch. It's odd that cubecart doesn't render the page correctly when this occurs. (updated to remove server/folder info)
  19. jasehead
    It's the same token that is used throughout the source code: <input type="hidden" name="token" value="d560a6106068910c62413e50e96e4681"> ...although probably not the token that cubecart is expecting, which is why it stumbles. Making the Add to Basket button disabled if the basket contains the last item in stock may solve the problem - no click, no break.
  20. jasehead
    Stock levels are not reduced when an item is added to the basket - that's right, and fine. To everyone else, no stock has been purchased so no change has been made. If someone else buys the item first then they win. But imagine this... You're in a very small but popular supermarket and it's late in the day so the shelves haven't been restocked. You see the last lemon - you only need one for a recipe - so you put the last lemon in your basket. It hasn't left the shop. You could still decide not to buy the lemon and it would go back to where it was. But for now YOU have the lemon in your basket. Then you look again and there's still a lemon to buy that isn't in your basket. You try and pick it up but the store attendant slaps your hand and tells you that you can't have that lemon because it's out of stock. "But I can see the lemon on display," you say. "But the lemon is already in your basket," the shop attendant replies. "Then why is it still on display?" you ask, and try to pick it up again. The store attendant replies by behaving in a bizarre manner by (a) showing you a distorted version of the store within the store, or (b) emptying your basket, saying nothing, and expecting you to start again. What a bizarre supermarket. So you leave without your lemon. While the customer is shopping, if they add an item to their basket where there is only one in stock then the Add to Basket button for that item should temporarily change and be disabled (just for that customer) while that item is in their basket. The trick would be to: check if an item in the store matches an item in the basket, and if the quantity in the basket is equal to the quantity originally available (considering product options), then change the "Add to Basket" button to (out of stock/unavailable/already in basket) and disable the button I see that product options complicates things, but the simple version would be that if ALL available product options for an item were exhausted by what was in the basket then the Add to Basket button for that item should change to disabled during that customer's session. Not to say that avoiding the Add to Basket click will solve the problem - but I can't think of another button or element in Cubecart that would cause a similar state change. BTW - I haven't noticed an error that says "the last of the stock is already in your basket", although I found it OK in my definitions file. --- The waterfall. With the "2018" version I only see a GET from Google Analytics and then nothing. With the copyright javascript removed for the "page within a page" version, there is one POST statement. Full URL has the store address followed by the query string ?_g=ajaxadd REQUEST DATA / FORM DATA Name: Value quantity: 1 add: 3022 token: d560a6106068910c62413e50e96e4681 That all looks fine. I don't really know what information you want to find. --- I've tested another site running 6.1.14 and was able to reproduce the "page within a page" effect - so it's nothing to do with my personal mods at least.
  21. jasehead
    I tried deleting my copyright script and testing again with the Foundation skin. Wow - what a mess. The page did render, but my logo on the left was by itself (looked like its own column), then the rest of the page squeezed into the remaining space. AND THEN at the bottom of the footer the whole page was rendered AGAIN in proper dimensions - except my logo was missing because that was at the top of the page. The search box was the right size. Chrome, Safari and Firefox all show the same result - the page rendered twice as described. My latest break-it-for-sure method is: Add a single item to the basket Click the Add to Basket item again Get an out-of-stock error Use a backwards button (or swipe) to return to the previous page Click the Add to Basket item again for the same item Repeat until it breaks This problem also occurs without any back button at all, only clicks on store buttons or logos, but is more intermittent. Maybe a result of locally cached pages, or pages in memory?
  22. jasehead
    I was able to replicate the problem with the latest Firefox 59.0.2 for Mac. The only item in the error log this time was: PHP Warning: Invalid Security Token in /home2/myserver/public_html/cubecart/classes/sanitize.class.php on line 152
  23. jasehead
    (sigh) I made the change to session.class.php but I can still get the store to fall over with a blank "2018" page. The error log* is no longer showing any user agent problems, but I am still getting lots of pairs of: PHP Warning: Invalid Security Token in /home2/myserver/public_html/cubecart/classes/sanitize.class.php on line 152 PHP Notice: Undefined variable: _GET in /home2/myserver/public_html/cubecart/includes/functions.inc.php on line 196 It still seems to fall over at the Invalid Security Token. I've found that I can make the "2018" error happen more reliably if I throw in a browser back button, but even if Cubecart doesn't like that it should still return a rendered page - and I've tested the javascript in my Copyright, the "2018" in the blank page is definitely generated from: <script type="text/javascript">document.write(new Date().getFullYear());</script> Of course, out of frustration, I could just change CSRF to false in the skin config.xml file - tempting. This could all be avoided if the Add to Basket button wasn't available for items that were already consumed by the pending basket - it's clicking an unavailable item that causes the problem. If a customer has your only copy already in their basket, then isn't it confusing for them to see the item as still available if they keep shopping? An Add to Basket button change (to Out of Stock?) should only apply for that customer during their session, not for everyone. Although, it would make even more sense if the button or error messages said something like "Already in your basket" rather than "Out of stock" (Why out of stock? Has someone else already bought this while I was browsing?). Better text and a disabled button would be the way to go because it would solve the problem, and also make the shopping experience better for the customer. * by error log, I mean the error_log file in the base cubecart folder on the server, or the System Error Log in Admin if debugging has been enabled prior to testing the store.
  24. jasehead
    I don't know where the URL I copied was (probably in the developer tools), but I did copy a URL with a token the same as what was in the source. All this is leading me towards not upgrading Cubecart to 6.1.14 and just sticking with 6.0.12 which seems more robust. I can't be running a glitchy store that is going to serve up random blank pages and empty baskets - I'm just going to lose sales and customers as a result. It's bad enough having a store that growls about CSRF - it's annoying to admin and it spooks customers. OK, assume that a normal vanilla browser like Safari or Chrome may send different User Agent strings and that this is at least causing part of MY problem. (A mobile browser rotated during a session may also send different user agent strings.) Is there anything I can change in Cubecart to make it less sensitive to user agent changes and still maintain some level of session cookie security. Maybe change the user agent to a random number instead. <?php $token = md5(uniqid(rand(), TRUE)); $_SESSION['token'] = $token; ?> Something like that, except still keep the IP address check and just replace the user agent with something random.
  25. jasehead
    There are no one-off error messages in the error log that coincide with the "2018" blank page. In Chrome, view-source for the broken page shows the expected generated source as if the page was rendered properly. The token in the URL is the same as the 15 occurrences of the token in the rendered page source. But in Chrome's developer tools, the HTML from the blank page is pretty simple: <html> <head></head> <body>2018</body> </html> This is an intermittent problem. Sometimes it's easy to make the cart fall over, other times it can take quite a lot of clicking around before it falls. If there was a code problem I'd expect it to break more reliably. I'm leaning towards an issue with CubeCart's security token method and webkit browsers. I've tested a vanilla Foundation skin and it still breaks, so the issue is not within the skin folder. When transferring mods from 6.0.12, I took care to preserve as much of the 6.1.14 code as possible, so all the token calls are still there - most of my changes are cosmetic. I have a heavily-modded catalogue.class.php (for search) but the vanilla version has the same result. I've searched through all modded code and can't find anything that might cause an issue with security tokens. Plugins and snippets are preorder plugin, partially shipped, and a tawk.to script at the end of main.php - but that's skin-specific. I'm wondering if the Safari user agent changes are an attempt by Apple/webkit to address browser fingerprinting. Would the same IP address but a user agent change upset Cubecart? Although, I'm seeing errors with different user agents even from googlebot: PHP Warning: Stored session data did not match DB record. Session aborted as possible session hijack. Old IP Address: '66.249.79.79' New IP Address: '66.249.79.79' Old User Agent: 'Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' New User Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' in /home2/myserver/public_html/cubecart/classes/session.class.php on line 702 Unless it's a reCaptcha issue. When the page breaks, in Safari's debugger (sources) I see that api.js from Google says: undefined is not an object (evaluating 's.parentNode') on line 22:7 ^or maybe it breaks because the page didn't load properly, I don't know.
×
×
  • Create New...