Feature #1458
closedHTTPS for the Commons?
Added by Matt Gold over 12 years ago. Updated almost 11 years ago.
0%
Description
Brought up by André during the meeting today. We should at least encrypt logins.
Updated by Boone Gorges over 12 years ago
- Assignee changed from Boone Gorges to local admin
- Target version changed from 1.4 to Not tracked
André, what's involved in getting an SSL cert? Does the GC have a preferred vendor?
Updated by local admin over 12 years ago
We use digicert [digicert.com] who are easy to deal with and moderately priced. We would need a wildcard cert for this, and I think those run at around $500/year.
Updated by Boone Gorges over 12 years ago
- Status changed from Assigned to Reporter Feedback
Thanks, André. We'll need feedback from Matt on the budget issue (I'm assuming it'll work).
Updated by Matt Gold over 12 years ago
Hi Andre,
Can you get me a quote on the budget request, along with any other info I'll need to make the purchase? I'll see what I can do to get it taken care of.
Best,
Matt
Updated by local admin over 12 years ago
Ok, so getting into the nitty-gritty of it, there's three option for purchase:
3 Years $475 per year ($1425) (You Save 20%)
2 Years $535 per year ($1070) (You Save 10%)
1 Year $595
What do you think?
Updated by Matt Gold over 12 years ago
Great. I think we'll go with one year for now and then buy a multi-year package next year. Can you give me or send me more details on exactly what needs to be purchased, keeping in mind that the actual purchase will be made by someone who is not tech-savvy? Many thanks.
Updated by local admin over 12 years ago
Matt Gold wrote:
Can you give me or send me more details on exactly what needs to be purchased, keeping in mind that the actual purchase will be made by someone who is not tech-savvy? Many thanks.
So once the PO gets processed we will receive a login account to digicert.com, from where we'll be able to download our certs. I guess the thing to do would be to send me the login info once we have it and I'll take it from there.
Updated by local admin over 12 years ago
Guys, the PO was issued for the new certificate and I was able to get it approved and issued.
I went ahead and installed and enabled it as well, so we can now access commons.gc.cuny.edu via https://commons.gc.cuny.edu.
Boone, next stop would be to redirect authentication requests to https://
, right?
Updated by Boone Gorges over 12 years ago
- Assignee changed from local admin to Boone Gorges
- Target version changed from Not tracked to 1.4
Awesome! Thanks, André.
Updated by local admin about 12 years ago
Matt Gold wrote:
Fantastic! Thanks, André!!!
You're welcome. My pleasure. Glad it worked out : )
Updated by Boone Gorges about 12 years ago
- Status changed from Reporter Feedback to Assigned
Updated by Raymond Hoh about 12 years ago
Cool that CAC is using HTTPS now!
I've just pushed a commit to the master branch that switches out various resources that were using HTTP instead of HTTPS when viewing the site via SSL:
https://github.com/castiron/cac/commit/a78a030c4ea6971bea170503192b5598435a869f
This will ensure that browsers will show their secure identification icon.
eg. Firefox - https://support.mozilla.org/en-US/kb/how-do-i-tell-if-my-connection-is-secure
This should hopefully address the SSL issues on the main commons.gc.cuny.edu site. However, should a concerted effort be made so HTTPS is ensured for the most popular CAC blogs? I say "most popular" because it will take a long time to debug various themes / plugins!
Boone: I've also introduced a file in /mu-plugins/ called cac-functions.php. My intention for this file is so all common functions on CAC sitewide will be placed here; BuddyPress-related fixes should remain in bp-custom.php.
Also, any reason why we have certain plugins like the sitewide footer as a regular plugin instead of in /mu-plugins/?
Updated by Boone Gorges about 12 years ago
- Target version changed from 1.4 to 1.4.1
- Estimated time set to 0.25 h
I forgot to flip this switch during the hubbub of the 1.4 release, so I'll do it next time around.
Updated by Raymond Hoh about 12 years ago
Commit 2604edc adds a few more SSL fixes.
Boone, there are a few other things that need to be addressed:
- WP AJAX Edit Comments plugin uses a rather, unorthodox way to generate its URL path. We need to modify this so the URL uses HTTPS. Is it okay to directly modify the plugin for now?
- CAC's "Recent Blog Posts" block embeds some inline images that may link to external sites. These images are insecure because they do not use HTTPS, however simply changing the URL to HTTPS might break the image. What do you want to do in these instances? If a user is viewing the site via HTTPS, maybe just remove inline images from the widget altogether?
Updated by Boone Gorges about 12 years ago
Thanks for your work on this, Ray.
I've had to hack WP AJAX Edit Comments in a number of places anyway, because of its numerous odd bugs. I don't believe it's being maintained anymore anyway, so have at it.
If a user is viewing the site via HTTPS, maybe just remove inline images from the widget altogether?
We should only need to do this for images that come from non-Commons sites, right? (We have a wildcard cert.)
===
More generally, I think we need to do a staged adoption of SSL for the Commons, so we've got time to fix bugs like the ones you're noting. Something like:
1) Force SSL login + block SSL for all other pages (htaccess redirects)
2) Offer SSL wp-admin (don't redirect from https in wp-admin)
3) Force SSL wp-admin (redirect away from http in wp-admin)
4) Offer SSL on front-end of blog #1 (though here we will always have the question of hotlinked content, which will always throw browser warnings)
I'd like to do (1) for Commons 1.4.1, and maybe explore (2) for an upcoming minor release. Ray, do you think this sounds reasonable?
Updated by Boone Gorges about 12 years ago
- Priority name changed from Normal to Low
- Target version changed from 1.4.1 to 1.5
- Severity set to Normal
In 1.4.1, I forced SSL logins. I'm going to punt the rest of this ticket to 1.5, so that we'll have adequate time to do testing on the fixes that Ray has been doing, and to discuss a strategy regarding secondary sites.
Updated by Raymond Hoh almost 12 years ago
If a user is viewing the site via HTTPS, maybe just remove inline images from the widget altogether?
We should only need to do this for images that come from non-Commons sites, right? (We have a wildcard cert.)
Yes, that's right. Remove inline images for those not from the Commons for the "Recent Blog Posts" block.
Just wanted to note down some other resources that are not correctly using HTTPS so we can come back and address them later:
- Google Custom Search (in bp-nelo header)
- BP Group Documents (CSS / JS)
Updated by Boone Gorges over 11 years ago
- Assignee changed from Boone Gorges to Raymond Hoh
Updated by Boone Gorges almost 11 years ago
- Status changed from Assigned to Resolved
Fixed the Google CSE asset URLs in https://github.com/castiron/cac/commit/ebdeaccb469ebf0ec4f35efb9c33f13380e23557
Fixed BP Group Documents in https://github.com/castiron/cac/commit/3517e76453b75bee8fb632aed547e0712fb90546
Going to mark this ticket as Resolved, as things should now load cleanly over HTTPS. If at some point we want to begin forcing HTTPS for something other than logins, let's do it in a separate ticket in a future release.