CUNY Academic Commons

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.

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

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?

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.

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.

Sent quote to your gmail.com address.

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?

Fantastic! Thanks, André!!!

Matt Gold wrote:

Fantastic! Thanks, André!!!

You're welcome. My pleasure. Glad it worked out : )

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/?

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?

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?

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)