[Train 89][Staging server only] "Unexpected error" message displayed in Communications preferences

VERIFIED FIXED

Status

Cloud Services
QA: General
VERIFIED FIXED
a year ago
a year ago

People

(Reporter: sorina, Unassigned)

Tracking

unspecified
Unspecified
Windows 10
Points:
---

Firefox Tracking Flags

(firefox55 affected, firefox56 affected)

Details

(Reporter)

Description

a year ago
Environment: 
- Staging Train 89 - Win 10 (64) - Build 56.0a1;

Steps to reproduce:

1. Launch Firefox and follow the account creation flow through each page of the Account Setup wizard;
2. Go to about:preferences#sync -> Manage account;
3. Click Change button from the Communication preferences area and click subscribe.

Expected:
The communication preferences drop down menu is displayed. Subscribed successfully message is displayed.

Actual: 
An "Unexpected error" message is displayed and user isn't able to subscribe/unsubscribe.  


Note: 
- https://irccloud.mozilla.com/file/7UqmuN0T/Screen%20Shot%202017-06-16%20at%2011.49.27.png
(Reporter)

Updated

a year ago
Blocks: 1372779
When I look at the response from the server I see:

{
  "status": "error"
  "code": 8
  "desc": "lookup_user always requires SSL"
}

which is weird because we've configured all three envs to point at https endpoints. I can also replicate this on dev. I'll dig into this some more.
So, if I do the request manually in curl with something like:

curl -H 'X-API-Key: ...elided...' 'https://basket.allizom.org/news/lookup-user/?email=jbuckley%40mozilla.com'

I still get the same error. This doesn't happen with the production basket server though, so maybe it's a config change on the basket side?

ni? :pmac for some illumination
Flags: needinfo?(pmac)
I believe this should be fixed now. It seems to have been an issue with our new AWS clusters which weren't correctly configured to inform the app whether requests were over HTTPS or not. That view has a check to see if it was requested securely which was always returning False due to this missconfiguration. I've taken those new clusters out of the DNS rotation and so it should work again. I'll get this fixed before adding them back. I verified the fix with :jbuck's curl command above. Please reopen if this has not resolved the issue.
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(pmac)
Resolution: --- → FIXED
Confirmed that this is working on dev & stage now. Thanks :pmac!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.