Project

General

Profile

Bug #6650

Force SSL for *.commons.gc.cuny.edu pages

Added by Boone Gorges almost 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
-
Target version:
Start date:
2016-11-08
Due date:
% Done:

0%

Estimated time:

Description

Starting in January 2017, Chrome will start showing "insecure" notices to users for non-HTTPS pages that contain password forms. See eg https://www.cnet.com/news/chrome-warning-insecure-http-websites-expose-passwords-credit-card-numbers/

On the Commons, we have a password form on every page (for logged-out users, at least) - in the toolbar.

We should start forcing SSL everywhere we can. For the moment, this means commons.gc.cuny.edu and *.commons.gc.cuny.edu. Most mapped domains don't have SSL certificates.

I'm going to go ahead and put this in the pipeline for 1.10.3. The code-level change will be pretty simple, but we should double-check to make sure we catch non-secure assets leaking through before then.

Ray, you're a watcher here - if you think of any blocking issues, please let me know.


Related issues

Related to CUNY Academic Commons - Feature #5525: Mapped domains should be administered over *.commons.gc.cuny.eduResolved2016-05-03

History

#1 Updated by Boone Gorges almost 3 years ago

  • Related to Feature #5525: Mapped domains should be administered over *.commons.gc.cuny.edu added

#2 Updated by Matt Gold almost 3 years ago

Thanks so much for catching this. Does this go for all CBOX sites? If so, perhaps I should send out an email to the CBOX list (and perhaps we should update NYCDH etc)

#3 Updated by Boone Gorges almost 3 years ago

(It may be the case that we're in the clear if the <form> element points to an HTTPS page as far as the browser warning is concerned, but we should make this change anyway.)

#4 Updated by Boone Gorges almost 3 years ago

Does this go for all CBOX sites?

It goes for every site on the internet. But Commons In A Box does not add a login form to the toolbar.

#5 Updated by Boone Gorges almost 3 years ago

  • Status changed from New to Resolved

I did some testing on cdev, and I think that the change looks good, so I've put it in place for 1.10.3: https://github.com/cuny-academic-commons/cac/commit/84e37f24f708003d6a5f71c99076d1ab97ebcfcf

While looking at it, I noticed that a previous fix for ensuring that HTTPS requests can't be made on non-Commons URLs was not working properly, due to our server migration. I've fixed that in https://github.com/cuny-academic-commons/cac/commit/0a0cd4b9d29bca35ed455ce39e4e77a01061ba2a

#6 Updated by Boone Gorges almost 3 years ago

  • Status changed from Resolved to Assigned

Crud, I just realized that this breaks local installations that use the commons.gc.cuny.edu URL and don't have a local SSL cert set up. Let me see if I can figure out a workaround.

#7 Updated by Boone Gorges almost 3 years ago

  • Status changed from Assigned to Resolved

I added a check against the LDV1 and LW3A subnets (based on SERVER_ADDR info), which is now hardcoded into .htaccess. So anyone visiting from localhost or 127.0.0.1 or whatever should not have any problems.

https://github.com/cuny-academic-commons/cac/commit/38e5e500d992dfe12d41bc83d302bfdb9c0b5fb2

#8 Updated by Boone Gorges almost 3 years ago

X-Forwarded-Proto is apparently not available in production, so I had to mod the rule after release: https://github.com/cuny-academic-commons/cac/commit/1702e6eaca3ad86bac0ad84f43f07211c440e6d0

#9 Updated by Raymond Hoh over 1 year ago

  • Related to Feature #9907: Ability to change error page for non-approved users? added

#10 Updated by Raymond Hoh over 1 year ago

  • Related to deleted (Feature #9907: Ability to change error page for non-approved users?)

Also available in: Atom PDF