Community
Participate
Working Groups
Created attachment 209214 [details] Screenshot of the problem indicator in the address bar on Chrome At least some (maybe all) of our pages display warnings when accessed by HTTPS. The problem, I believe, is that several images are rendered using HTTP. Some of these images come from the theme. The Nova header, for example, includes the "other site" icons using "http://..." src values. Maybe it's just me, but I find this off-putting. I assume that others might as well. Reported by Google Chrome: "Your connection to dev.eclipse.org is encrypted with 256-bit encryption. However, this page includes other resources which are not secure. These resources can be viewed by others while in transit, and can be modified by an attacker to change the behavior of the page." I'll submit a patch for consideration.
Created attachment 209216 [details] Patch Phoenix loads the top-right icons from the icons library on dev.eclipse.org. Attached is a patch that will detect whether https is used or not.
(In reply to comment #1) > Created attachment 209216 [details] > Patch > > Phoenix loads the top-right icons from the icons library on dev.eclipse.org. > Attached is a patch that will detect whether https is used or not. I'm pretty sure that I said that I was going to submit a patch :-( The documentation for $_Server['HTTPS'] states that the value is non-empty (not anything specific). I recommend changing the check to: if($_SERVER['HTTPS']) { $image_protocol = "https"; } +1 otherwise. I started a more general solution for dealing with images in the project stuff: I have an images script that provides commonly-used images. I use it primarily for consistency of images across pages, but it also provides a handy bottleneck for dealing with this sort of issue. But this is a little bigger than what we need now.
Created attachment 209219 [details] Patch v2 > I'm pretty sure that I said that I was going to submit a patch :-( Sorry, I had already started this as part of the auth change. I've changed the patch to use isset. On my dev box, $_SERVER['HTTPS'] isn't even defined in $_SERVER, which throws a warning.
(In reply to comment #3) > I've changed the patch to use isset. On my dev box, $_SERVER['HTTPS'] isn't > even defined in $_SERVER, which throws a warning. I believe that this is a reasonable interpretation of the documentation. +1
The patch fixed all the http images. The Google CSE in the nav bar is still using http, though. I can think of two solutions: 1. We hack Phoenix to allow disabling the Google CSE. In the context of Site Login, the Google CSE is really not required. 2. We hach Phoenix to detect https and alter the calls to CSE to use https as well. My vote is 1.
(In reply to comment #5) > The patch fixed all the http images. The Google CSE in the nav bar is still > using http, though. > > I can think of two solutions: > > 1. We hack Phoenix to allow disabling the Google CSE. In the context of Site > Login, the Google CSE is really not required. > > 2. We hach Phoenix to detect https and alter the calls to CSE to use https as > well. > > My vote is 1. #2 seems more consistent. "Allow disabling" means that's on by default and must be explicitly turned off. This is just one more thing that implementers will forget to think about. Option 3 might be to just automatically exclude the Google CSE if HTTPS is being used. But I still like #2 better.
Ok, the Google CSE seems to have fixed it. Can you confirm on your browser of choice?
(In reply to comment #7) > Ok, the Google CSE seems to have fixed it. Can you confirm on your browser of > choice? +1 in Chrome and Firefox on Fedora 14.
Fixed it is.
(In reply to comment #9) > Fixed it is. Got the Star Wars Bluray Box set for Christmas, did you?
Lolling I am, for the box set, I have not.
