The Case of the Truncated HTTP Requests
I just got done with a support email for one of our customers at Taurus. He was having trouble with logging in. I checked all the usuals: there were no errors in console, he wasn't blocking our site data, resetting his password yielded no problems on our end, and he was still locked out.
We started diving into the site logs to see what kinds of entries we were seeing from him; that's where we found the culprit. All of his requests include a truncated form of his email, some with a missing password, some missing email and password entirely. Now we knew what the problem was, we just didn't know what caused it.
Parameters came after the email, so it couldn't have been a URL size limit (and even then it was pretty short).
The length of the truncated email held nothing of any significance.
Certainly, he couldn't be making that many typos.
Maybe his autocomplete saved a truncated form of his email and he was accidentally submitting that? Nope. He verified that he was, in fact, using his email address in its entirety.
It's worth noting that we had just released the new version of Taurus that uses AngularJS. The controller that handles login looks like this:
$scope.login = (email, password) -> Manager.api "/login/create.js", data: email: email password: password
That's when I realized something in Angular must not be triggering when autocomplete fills out a form (we grab the email from its model rather than pulling the value out of the DOM element). So when the user attempts to login, rather than sending over what's actually in the text field, we're getting what was physically typed into the keyboard (so partial email addresses, or in some cases, nothing at all).
A quick search reveals that this is, in fact, a known issue: https://github.com/angular/angular.js/issues/1460
No problem. I quickly fixed it by pulling in the data using regular old Javascript instead and pushed it live so our autofill users could get on with their lives.
