Discussion posts sent over unencrypted connection

RESOLVED FIXED in 3.2

Status

addons.mozilla.org Graveyard
Public Pages
--
major
RESOLVED FIXED
11 years ago
2 years ago

People

(Reporter: Wladimir Palant, Assigned: wenzel)

Tracking

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
Go to URL above, the form to post a comment has http://addons.mozilla.org/en-US/firefox/discussions/post.php as its target - it should use HTTPS however. To post the comment I need to accept two security warnings.
(Assignee)

Updated

11 years ago
Duplicate of this bug: 377759
This will be because the Vanilla infrastructure isn't aware of the special magic moz-req-method header that the netscaler uses to tell us how we were requested.
Wenzel: did you enfixify this?  I remember you were looking at it.
Target Milestone: --- → 3.2
(Assignee)

Comment 4

11 years ago
Okay. I am sorry I was unable to figure out why the discussions lose the environment variable that's being set in the htaccess file.

But I added the request header check from bootstrap to the discussions settings as well. This results in the POST urls getting built correctly.
Assignee: nobody → fwenzel
(Assignee)

Comment 5

11 years ago
Created attachment 267711 [details] [diff] [review]
Discussions https awareness

Yet another punch into the face of the https handling. Shaver, please approve unless you have an idea how we can fix it otherwise.
Attachment #267711 - Flags: review?(shaver)
Comment on attachment 267711 [details] [diff] [review]
Discussions https awareness

r=shaver -- any idea how to test it? :)
Attachment #267711 - Flags: review?(shaver) → review+
(Assignee)

Comment 7

11 years ago
well, we need to send a request with the (fake) Netscaler-style HTTPS request header and see if the URLs made by the discussions code are https://.

I just notice, if you are not actually on a http connection, this "fake" request leaves all cake parts of the page with http:// anyway, but I think that's beyond the scope of this bug as it won't matter in production.
(Assignee)

Comment 8

11 years ago
There you go. I did as I said and wrote a test for this, checking if the "next page" link is https when the NS HTTPS request header was sent.

The actual fix and the test are both in SVN, r4413.

Marking this fixed. Woot.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Duplicate of this bug: 384889
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.