Recently, I was looped in to the following issue reported by a client we recently onboarded at Something Digital…
Customers are placing orders and seeing the wrong order confirmation page. Also, customers are logging in and seeing the wrong customer account.
Yes. It’s as scary as it sounds.
This was a tricky one, but in the end I got to the bottom of it. Here, I’ll document the saga and solution.
NOTE: This post is based on the the New Relic PHP Agent as of Version 184.108.40.206
Recently I received a report from a client which read something like this…
Checkout is blocked on our website. Customers cannot place orders. Help!
I navigated to the website in question, added a product to my shopping cart and, upon clicking the “checkout” button was directed to a screen where I was prompted to select my “complimentary sample product”.
There, I selected a random “sample product” at which point a “loading” overlay appeared on the screen. I waited a few seconds and soon realized the overlay wasn’t going to disappear. I was effectively “blocked” from getting to checkout…
Here I’ll provide more details on the issue and my findings…
Recently at Something Digital I’ve been working with a client who’s been having a lot of trouble setting up Google Shopping ads.
After creating a product feed and submitting it to Google Merchant Center nearly half the products were listed as “Disapproved”. Drilling into these products in Google Merchant Center product details we saw the following error.
This stuck me as strange as, upon a quick check of the site’s robots.txt file I saw nothing that would prevent Googlebot from crawling the images in question.
We were ultimately able to resolve the issue, which, as suspected, had nothing to do with the robots.txt file. Here I’ll document my findings…
Something I do very often is add the current date to a filename from the command line.
Historically, I’ve always done something like this…
$ mv foo.txt 2018_02_14_18_07_foo.txt
It always felt dirty though…why should I manually type out the current date when I’m sitting in front of a computer which is equally if not more capable of doing that exact thing?
While I long put off researching this, today, I finally turned to Google in hopes of finding a more sane approach.
As a follow up to my recent article “How Magento Generates Admin Secret URL Keys” I’ve decided to take a look at yet another mechanism Magento uses to protect against CSRF attacks…form keys. In this post we’ll dig into Magento’s core code to understand how exactly, they are generated in both Magento 1 and Magento 2.
Recently, while looking into a vulnerability for the Magento Bug Bounty I needed to generate the secret key for an admin URL. While I’d long known that Magento adds these keys for security purposes (specifically to prevent against CSRF attacks) I never understood how exactly these keys are generated. In this post, I’ll document my findings.