Based on the above report on "no @ in email workaround" (thanks you guys) I did more tests and here is my conclusion:
Conclusion A: Their backend now starts to check for session TOKEN and packageID/labelID values.
Here is my thoughts on the flow of their backend logic:
1) When the form is submitted. Form validation is performed for form fields.
2.1) If form validation passes (all data are valid), the session token is checked. If there's no valid token and packageID/labelID, backend throws error as we saw lately and redirect to the Sign In page.
2.2) If form validation failed, backend redisplay the label form and give us a chance to fix the data. No token and and packageID/labelID checking.
Based on the above logic, I've Conclusion B:
Conclusion B: Using an invalid Email address is just one of the workarounds. Using any invalid data would do the same trick (for example making any required data "missing").
To verify Conclusion B, open usps_autofill_button.php and delete the following line:
Code:
<input type="hidden" name="returnZipcode" value="<?php echo addslashes(USPS_RETURN_ZIPCODE); ?>" id="returnZipcode">
And autofill works. Note you don't have to use an invalid email address with this test.
Now we just need to find an easy to fix field and intentionally invalidate it. I see "Shipping from ZIP Code" and "Size" very good candidates!!!
Wow~ analyzing a blackbox is fun!
Bookmarks