Sheridan Posted June 5 Posted June 5 We're seeing a regular problem when using various sites to buy things - on the checkout page the 'express' check panel with the Shop, Paypal and GPay buttons renders them as grey/blank buttons and the rest of the page doesn't work - even if you want to enter a credit card rather than use any of the express option the buttons to proceed are always greyed out I have all of the shopify sites bypassing the filter, but this crops up on every site like this, until I exclude that site from https inspection, which is becoming a real pain! Example photos are exactly what happens on these sites, they must be using a common platform but apart from shopify I can't see what else is involved and why https whitelisting the site is necessary to proceed?
ZeroHour Posted June 5 Posted June 5 Open the browser developer tools and switch to Network tab then reload that page and see if any errors are appearing to hopefully give a clue.
TechMonkey Posted June 5 Posted June 5 Just seen elsewhere that Shopify are having major issues. Might be best to put this off until after the weekend and see if it is still doing silly things on Monday.
Sheridan Posted June 12 Author Posted June 12 Still having a right problem with this - another example today that uses shopify that I cannot get to work, even bypassing https inspection isn't working on books2door.com Inspecting the results in Edge shows two errors: Failed to find a valid digest in the 'integrity' attribute for resource 'https://www.books2door.com/cdn/shopifycloud/checkout-web/assets/c1/context-browser.C_iFu_A5.js' with computed SHA-384 integrity 'Bt0EwXKQB9jsAR6+IWhIxKfUcY+NBPA84fiB2ZEs+N2ff3aHj9Pd6gtnMGD1qxEm'. The resource has been blocked. app._Zoih-gS.js:10 Uncaught (in promise) TypeError: Failed to fetch dynamically imported module: https://www.books2door.com/cdn/shopifycloud/checkout-web/assets/c1/context-browser.C_iFu_A5.js Both of those urls open in a browser page and show the javascript so its not blocked. Switching off tracking in edge makes no difference. I'm sure this will be some tracker or spying based issue but the smoothwall doesn't show anything being blocked either!
TechMonkey Posted June 12 Posted June 12 Do you have a WebSockets exception category/group? I have found that is a solution more and more.
Sheridan Posted June 15 Author Posted June 15 On 12/06/2026 at 15:26, TechMonkey said: Do you have a WebSockets exception category/group? I have found that is a solution more and more. We don't have anything like that currently setup - something to look into as this is becoming a nuisance
ChetterHummin Posted June 16 Posted June 16 (edited) On 12/06/2026 at 13:58, Sheridan said: Still having a right problem with this - another example today that uses shopify that I cannot get to work, even bypassing https inspection isn't working on books2door.com At that point, the next step is completely exempt the source IP of the client (temporarily) so you know no filtering is being applied at all for the test. If you still get the issue even then, it could be something doesn't like the public IP of that particular internet line. Edited June 16 by ChetterHummin
fizzymilk Posted July 17 Posted July 17 On 12/06/2026 at 15:26, TechMonkey said: Do you have a WebSockets exception category/group? I have found that is a solution more and more. Having the exact same issue here with Smoothwall and all Shopify sites. I've tried Chrome's new AI console error analysis tool, it more or less confirms that the .js files are being altered at some point and the hash check is failing. We've put the user in bypass mode, added every shopify URL we can find to the allow-list and still no joy. We haven't tried anything with Websockets so will look into this.
Sheridan Posted July 17 Author Posted July 17 Its a nuisance, I've just been adding https exceptions for the ones that play up - fortuntely for us (and our finance teams sanity) we've covered most of the commonly used ones! 1
fizzymilk Posted July 17 Posted July 17 1 hour ago, Sheridan said: Its a nuisance, I've just been adding https exceptions for the ones that play up - fortuntely for us (and our finance teams sanity) we've covered most of the commonly used ones! Funnily enough we've had some success this morning by doing this, but only if the user is on Firefox?! So Smoothwall was definitely the issue, but there must also be something in our G Workspace policies. But! There was no errors saying that anything was blocked? So this shouldn't have worked? I'm more confused than I was before, but at least someone is able to buy something.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now