At Grand Valley, we’ve been focusing on the non-database/journal systems, since it’s easier to control those than anything else. (You can read about my initial foray into getting just a small section of our subscription databases to wotj with HTTPS here: https://matthew.reidsrow.com/worknotes/177 ) Our own servers have been forcing HTTPS for over a year, so that helped us a little bit. But most of our tools are hosted by vendors, so we did an audit this month to determine what was working and what we needed help with. The good news was that pretty much all of our systems already support HTTPS, but some do not *force* HTTPS connections. We’ve already worked to address this by making sure all our links to systems on our website, LibGuides, forms, etc. go to HTTPS, and changing settings in our discovery systems and other places to send folks via HTTPS to our link resolver and catalog.

Here is the list of patron-facing systems I compiled and the current status of HTTPS support, and where we’re at. I hope it’s helpful to anyone else trying to come to terms with this change:

• bepress Digital Commons: they announced vague support for HTTPS connections earlier this year, but have offered no details and told us last week that no progress has been made. (No doubt they have been busy rolling around in the pile of dirty money from Elsevier.) The big question we have is that we have a CNAME for our instance, which would require a root-level wildcard or a specific certificate for the subdomain. Our institution won’t let us use the root-level wildcard (*.gvsu.edu) on a hosted server, so we’ll have to buy a certificate for this. I asked for details on a CSR and they were like, “What? We’re not there yet.”
• Our campus CMS already forces HTTPS.
• LibGuides: now supports custom domains and certificates through a slick GUI admin console in LibApps. We’re purchasing a certificate for this, since it has a URL structure that doesn’t match our current wildcard certificate.
• LibChat, LibCal, LibAnswers: GUI certificate support is coming in a few weeks. We’ll add our wildcard (*.library.gvsu.edu) to these once we can.
• Ares (Course Reserves) and Illiad (ILL): both hosted instances already force HTTPS on all connections.
• ArchivesSpace – hosted now supports HTTPS (it uses the *.lyrasistechnology.org URL, so we don’t need a certificate.) I don’t think it forces HTTPS, though, so we currently direct folks there over HTTPS and will be looking at how the new OAI-PMH feed emphasizes HTTPS and checking our MARC records for support. In addition, we’ll ask for an option to force HTTPS connections on all visits.
• Omeka – This is hosted on our servers, so it already supports HTTPS and forces HTTPS connections.
• 360 Link link resolver: supports HTTPS, and we direct *a lot* of our traffic there, but not everything. For instance, today I realized that GOBI links were still using http. I’ve put in a feature request on the Ex Libris idea exchange to give an option to force HTTPS connections if you want to vote it up. (It already has almost 50 votes and I added it late last week.) http://ideas.exlibrisgroup.com/forums/564566-summon/suggestions/31025644-add-option-to-force-360-link-to-load-over-https  (I got the impression that this feature is already scheduled for a December release, since they are adding it to EJP 2.0, but don’t quote me on that.)
• EJP 2.0 (eJournal Portal from ProQuest/Ex Libris): Was told an option to force HTTPS is coming in the December release. There are still a few issues even if you route folks there over HTTPS, which I have tickets in on:
o If you use the 1.0 form syntax and route to an https connection, you will be redirected to http. You can get around this by using the 2.0 syntax, although that requires JavaScript. They will fix this in the December release. My ticket number is 00462308 if you want to follow up.
o Syndetics book covers still use HTTP, even when the rest of the site loads with HTTPS. This is on the same ticket above. They’re waiting to hear from the Development team about fixing this. I recommended always using HTTPS, but at least making the images load relative to the selected protocol.
• Summon: We currently direct all our forms, links, etc. that we can control over HTTPS. I submitted a feature request to add an option to force HTTPS connections. It’s here: http://ideas.exlibrisgroup.com/forums/564566-summon/suggestions/31025608-add-the-option-to-force-summon-to-load-over-https 
• Sierra/WebPAC Pro from III: The OPAC for Sierra currently switches to HTTPS when you log in, but otherwise connections are http. We have our links and forms set to send users over HTTPS, but sometimes they find ways to get there over HTTP so we asked for an option to force HTTPS. Last year I submitted this same feature request, and they told me, no joke, to “do it with JavaScript.” 0_o I submitted another ticket (Case #576013) which had the following effect:
o At 6:00am on SATURDAY, they put in a temporary HTTPS redirect on the apache server (it lives on campus, but they manage it.) They didn’t ask us if we wanted to try this, they just did it ON A SATURDAY MORNING 2 days before classes started.
o All our clients went down
o We lost connection to our INNREACH consortial catalogs
o Still only about half the pages were getting redirected to HTTPS
o They reversed the change, and then bizarrely closed the ticket. I’m still so mad about this weekend I haven’t written them back to reopen it because I’m afraid of what they will do!! 

There are still no doubt tons of places where we’re missing updating URLs for tools with https, like all the databases where we have our link resolver information stored (we have 300 databases, so it will take a while to update those.) But by hitting the main preferences in our most popular tools to link to HTTPS versions of other tools, updating our HTML forms to direct to HTTPS versions, and doing a find/replace in LibGuides to make sure all the URLs to the catalog and Summon were going to https, we do get most of the traffic. Hopefully with enough pressure from all of us, the vendors will get this sorted out on their end (although I don’t have much hope for III).

So far the only vendor to address this openly has been Springshare: http://blog.springshare.com/2017/08/24/https-a-palooza-and-what-are-we-doing-about-it/ 

I’d love to hear what others are doing, too.

--
Matthew Reidsma
Web Services Librarian, GVSU.edu/library
Editor-in-Chief, WeaveUX.org
 
Report a problem with a GVSU Library system at https://prod.library.gvsu.edu/status/?problem 
 
PGP: 25AA 0DE3 B9E9 658F 04A2  EEF0 0DEF 555D F8BD 785B


On 8/30/17, 10:44 AM, "Code for Libraries on behalf of Benjamin Florin" <[log in to unmask] on behalf of [log in to unmask]> wrote:

    How is everyone handling the switch to HTTPS-everywhere-all-the-time next
    month?
    
    In October Chrome v62 will start marking all pages served over HTTP with
    text input elements as insecure (
    https://blog.chromium.org/2017/04/next-steps-toward-more-connection.html).
    Almost every page we serve or link to has a search box on it, so most
    libraries will effectively have to go HTTPS-only.
    
    Switching sites on our own domain to HTTPS-only will be easy, but requiring
    HTTPS from the databases, journals, repositories, etc that we link to is
    tougher.
    
    How is everyone else dealing with this? Do you have a sense of the scope of
    the problem? Are you already HTTPS-only?
    
    Thanks,
    Ben