So. I bought a new phone, for which Samsung and a specific retailer are holding a cashback promotion. Buy phone, go to website, enter some stuff, get money back. Sounds easy, right?
Well, it's Samsung we're talking about here... so nope.
First of all...
You can't just submit a form, you need a Samsung Account for that. As part of the registration process, you'll need to come up with a password. So, I fired up my password manager, had it generate a strong password, and entered it into the form.
(I changed type=password
to type=text
for demonstration purposes)
Hm.
Of-friggin'-course.
After changing it back to the generated password and leaving the password box, I noticed a bit of text underneath it.
Hm. What happens if I truncate my password to 15 characters?
Of course. A shitty regex. Just what we need.
And then...
The registration form itself is bollocks. It's a multi-step form, which uses Angular on the frontend, and it's sloooooowwwwwww... utterly slow. Autocomplete fields (such as 'which product did you buy?') take seconds to come up with input suggestions, and the "validation" step can take up to 45 seconds without giving any feedback about what's going on.
There's plenty of tracking going on, as well. Omniture, Samsung's own tracking logic, and even Microsoft's Visual StudioAzure Application Insights. Which provides nice log entries like this:
From the Application Insights docs:
Daily cap: When you create an Application Insights resource in the Azure portal, the daily cap is set to 100 GB/day. When you create an Application Insights resource in Visual Studio, the default is small (only 32.3 MB/day). The daily cap default is set to facilitate testing. It's intended that the user will raise the daily cap before deploying the app into production.The maximum cap is 1,000 GB/day unless you request a higher maximum for a high-traffic application.
Use care when you set the daily cap. Your intent should be to never hit the daily cap. If you hit the daily cap, you lose data for the remainder of the day, and you can't monitor your application. To change the daily cap, use the Daily volume cap option. You can access this option in the Usage and estimated costs pane (this is described in more detail later in the article). We've removed the restriction on some subscription types that have credit that couldn't be used for Application Insights. Previously, if the subscription has a spending limit, the daily cap dialog has instructions to remove the spending limit and enable the daily cap to be raised beyond 32.3 MB/day.
I don't think this particular form will get 100 GB/day of tracking data pushed to it, but I will believe 32.3 MB/day. So, someone at Samsung probably decided that putting this in production was a good idea and never bothered to monitor the data rates. Because of this, they're missing out on monitoring data.
And finally...
When I got to the last step of the process, the "Submit" button simply didn't do anything. I did see stuff getting sent to the tracking services, but no other requests were made to log my submission. There were no script errors, either. Which led me to believe that something was failing...
I fired up the debugger, waned my way through thousands of lines of Javascript to figure out where the submission was handled, and discovered that there was one final validation taking place. Which failed as I didn't accept the terms and conditions checkbox.
<div class="row ng-hide">
<label>
<input type="checkbox" name="termsCheckbox">
I agree with whatever Morbs just said.
</label>
</div>
See that little ng-hide
? That's a way to apply display: none;
to the element. Samsung's validation logic, however, required this particular box to be checked. Once I removed the ng-hide
from the row and pressed "submit", a spinner appeared and stayed visible for a minute. After that, I finally got confirmation that my submission was successful.
Seriously, did they even test this form before it went live?