376567 - Discussion posts sent over unencrypted connection

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[Wladimir Palant]

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.

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Wenzel: did you enfixify this?  I remember you were looking at it.

Comment 4

[Fred Wenzel [:wenzel]]

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.

Comment 5

[Fred Wenzel [:wenzel]]

Attachment: 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.

Comment 6

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 267711 [details] [diff] [review]
Discussions https awareness

r=shaver -- any idea how to test it? :)

Comment 7

[Fred Wenzel [:wenzel]]

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.

Comment 8

[Fred Wenzel [:wenzel]]

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.