Authenticated Pages Should Only be HTTPS



8 years ago
6 years ago


(Reporter: mcoates, Unassigned)




(Whiteboard: [infrasec:tls][ws:high], URL)


The site allows pages to be served over HTTP or HTTPS including the login page, account creation, and pages viewed after the user is authenticated.  These pages can disclose sensitve data including the username, password and session id

Recommended Remediation

- The login page and account creation page should only be accessible over HTTPS.  
- Authenticated pages that are not publicly accessible should only be accessible over HTTPS.
- Pages that are public, but can also by accessed by an authenticated account, can be accessed over HTTP provided that the session ID is set as HTTPOnly. This configuration will essentially allow the user to browse the public pages as an unauthenticated user.

Comment 1

8 years ago
(In reply to comment #0)

This is just due to how the staging server is configured... we already serve the login, registration and authenticated pages over HTTPS on production.  You can verify the Deki stuff on

IT probably had their reasons for not implementing the staging server the same as production, so not sure if there is anything to fix in this bug.

Cc'ing Oremj to see why stage9 does not behave like production.
Is the intended location of this app?  Are we still on track to host all uploaded content on another domain?

Comment 3

8 years ago
(In reply to comment #2)
> Is the intended location of this app? 
Yup... it will live at

> Are we still on track to host all uploaded content on another domain?

Les or Austin can probably give a definitive answer, but from what I understand, the Demo Studio uploads will live on  But I could be wrong, since there was talk about using the or domains for something.
I've discussed with Les: - WOW demos - DR demos

He mentioned that the Django app will write to a local directory... Hopefully IT can configure this to be an NFS or some kind of share so that the files automatically show up on a file server that's Apache can serve up.

I've not filed the IT bugs, etc to make that happen, I'll defer to Les on the actual design he went with...
I'm assuming an NFS mount on the app servers is the easiest way, since that's how IT had me do it in the past. 

The Django app has settings to point it at a filesystem path (eg. an NFS mount) and a base URL for where those files are served (eg.

We have bug 632138 to track deployment of MDN 0.9.3, which includes the Demo Studio.
Where is this bug? Not sure what the next steps are.
Target Milestone: --- → 0.9.3
I'm thinking this boils down to config difference between staging and production. Can we close this?
Last Resolved: 8 years ago
Resolution: --- → FIXED
Yes, we can close this. We'll take a look at prod when its available to double check the issue.
Component: Demos → Demo Studio / Dev Derby
Product: Mozilla Developer Network → Mozilla Developer Network
You need to log in before you can comment on or make changes to this bug.