905536 - Bad URL encoding sometimes mis-encodes some characters

Status: RESOLVED FIXED

(Marketplace Graveyard :: Consumer Pages, defect, P2)

Description

[Matt Basta [:basta]]

Sometimes we see user tokens in log output, especially when there's plus characters in the user's email address. At some point in the process, the user token is being improperly encoded (or decoded) such that the plus is not being converted to %2B. This has a number of side effects:

- User token in some logs
- Request caching does not work sometimes
- Cache rewriting does not work sometimes

For users with these email addresses, this causes a pretty significant perf hit. In the past, this has also resulted in certain features not working for these users (due to other bugs which were exposed by the issue).

This bug affects Commonplace code.

Comment 1

[krupa raj[:krupa]]

This also affects testing since we see weird behavior when logged in with an email id with + in it. These email ids are used often to verify a new user behavior.

Comment 2

[Matt Basta [:basta]]

https://github.com/mozilla/fireplace/commit/6bc72a5793f69310dfdb920429b279082985562f
https://github.com/mozilla/fireplace/commit/55924d58ad7680d73da363dc35a4777e2fdbb50e
https://github.com/mozilla/commonplace/commit/9f817bac9750f7438e73347c992edb11c33d1aac

This fixes the issue. We were un-escaping spaces (+) after we were doing a decodeURIComponent. It should have been the other way around.

Commonplace projects will receive the update in version 0.1.0 or 0.0.12 (whichever is released first).

Comment 3

[Matt Basta [:basta]]

Marking qa- since the STR are very obscure and you need a specially-crafted email to reproduce. If you want to test that it's working, run the following in your console:

require('utils').decodeURIComponent('foo%2Bbar')

On affected sites (presently prod/stage), you'll see "foo bar".
On patched sites (presently just -dev), you'll see "foo+bar", the correct value.