Addons-frontend: TAARDIS: Pass hashed client id to TAAR via AMO API request

[muffinresearch]

As TAAR moves away from being a shield study instead of receiving the client-id via a query string set by the add-on the client-id will be available in hashed form as a cookie a HTTP header sent by the browser.

Bug with the details of the Firefox implementation is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1489531

This bug is to cover reading that cookie header and passing the hashed id down to TAAR via the AMO api.

For QA: this change will only work in the context of about:addons, so you have to update the discoverURL pref to https://discovery.addons-dev.allizom.org/%LOCALE%/firefox/discovery/pane/%VERSION%/%OS%/%COMPATIBILITY_MODE% (for -dev).

Then:

• set your own client ID to a test ID that returns recommendations, e.g., 00000000-0000-0000-0000-000000000000. You can change the client ID in /path/to/current FF profile/datareporting/state.json:

  • open FF and navigate to about:profiles
  • find "This is the profile in use and it cannot be deleted." and open the root directory

  • open datareporting/state.json and replace the content of this file with:

    {"clientID":"00000000-0000-0000-0000-000000000000"}
    

  • restart your browser
• open about:addons and load the disco pane
• you should get recommdations

If you repeat those steps with 00000000-aaaa-0000-0000-000000000000, you should not have the recommendations but a different list with editorial choices.

[muffinresearch]

We can probably pass this down in the same way the current non-hashed client id is passed but that should be discussed with whoever is implementing https://github.com/mozilla/addons-server/issues/10174

[rebmullin]

will it be sufficient if I just sent credentials:include or do I need something else?

[rebmullin]

will it be sufficient if I just sent credentials:include or do I need something else?

I did a little bit of playing around and tried passing with the credentials option but I don't see any difference in the results. My understanding is that not I might not anyway for various reasons (per Stuart's notes:

Ideally you should see different add-ons but that depends on if TAAR is fully working on its development endpoint, how much data your client id has already transmitted (in order to provide recommendation) and whether you have add-ons in that profile.

)

hey @diox, can you advise?

[diox]

As long as you do get a hashed client id from the browser, and it does look like a sha256 of your telemetry id, and you pass that down to the AMO API, everything should work out in the end.

I haven't tried the TAAR dev endpoint with real data - I've been using the sha256 hashes of the known test client ids for testing. In any case, AMO API wrapping that endpoint is not ready yet, but it'll be soon, just need to get https://github.com/mozilla/addons-server/pull/10304 approved and merged.

[diox]

Note that you should pass the client id as a query parameter just as before, the API ignores all cookies. I updated the API docs to make it clearer.

[willdurand]

@muffinresearch the patch merged for this issue contains a feature flag. @rebmullin will correct me if I'm wrong but I think it is only enabled in dev so far.

[muffinresearch]

@rebmullin @willdurand This will need to go into prod next week to make the 29th January deadline so we'll want to get this config'd on for stage and prod ahead of the Monday tag.

[rebmullin]

@muffinresearch, do we still need a feature flag then if we have a check for disco?

[willdurand]

@muffinresearch, do we still need a feature flag then if we have a check for disco?

I think it would be safer in case we need to disable it if something goes wrong.

[AlexandraMoga]

@willdurand I get the impression that the implementation method changed a bit since the issue was first filed, i.e. we are sending the hashed client id in the request header, not as a cookie. Please correct me if I'm wrong.

Also, it would be useful to know what my test approach should be, besides verifying that the client id is correctly sent.

[willdurand]

@willdurand I get the impression that the implementation method changed a bit since the issue was first filed, i.e. we are sending the hashed client id in the request header, not as a cookie. Please correct me if I'm wrong.

Also, it would be useful to know what my test approach should be, besides verifying that the client id is correctly sent.

Correct, let me update the description of this issue.

[willdurand]

@AlexandraMoga updated!

[AlexandraMoga]

Verified fixed on AMO -dev with Nightly 66, Win10x64

I've tried with two different clientIDs that are bringing results on -dev and a clientID that doesn't bring recommendations.

The clientID is passed correctly via the request header and recommendations are brought, or not, depending on the used ID.

00000000-0000-0000-0000-000000000000

11111111-1111-1111-1111-111111111111

And a client id that doesn't bring recommendations => shows the addons set up via Discovery Admin

00000000-aaaa-0000-0000-000000000000