Many Indian Koha users use the GoogleIndicTransliteration option to offer their users the facility to search in Indian languages on the OPAC. This nifty feature allows users to phonetically type in their search queries in Indian languages in order to search catalogs that are (a) multi-lingual or (b) in a Indian language other than English.
However, if you are security minded (and you *should* be if your OPAC is on the Net and allows your users to log in) and you decide to serve your site over to SSL (i.e. https), then guess what? The GoogleIndicTransliteration feature stops immediately with the browser console showing MIXED CONTENT error. Every single Koha version from 3.18.0 (when this feature made its way back into Koha after a long hiatus) up to the latest 16.05.2 (released on August 1, 2016) are affected by this problem.
I do not have time, just show me how to fix this
If you are in a hurry, jump over to the section “Your options until the patch is officially released” at the end of this post. Remember to read the caveat and the assumption, you have been warned! 😉
Why is HTTPS so important?
Let’s take a moment to understand why HTTPS is so important. Let’s assume that your Koha server is on your institutional LAN / intranet or hosted online, either on the cloud or on your own server connected to the Internet via a leased line.
Without HTTPS, every time you login into Koha (staff and/or OPAC) and perform *any* ILS transactions (e.g. patron contact information change, holds, fines, circulation etc) all of that information is available in PLAIN TEXT to everyone on your network.
If you are only connected to your institutional network, then that is the direct extent up to which anyone can see what you are doing. If your server is accessible over the Internet, then basically the whole wide world can see what you are doing. For instance, when you login over HTTP, it is actually the equivalent of writing down your username and password on a postcard and mailing it across the globe. Anyone who handles it during transit, or wants to, can simply read it. That’s why the world is moving away from the plain vanilla HTTP.
In simple terms, HTTPS on the other hand creates an end-to-end encrypted “tunnel” between your server and the browser that is requesting access (e.g. to the OPAC). Think of it as a secure, sealed box with the contents inside and only you, the user, have the “key” to unlock it. The actual process is depicted in the graphics below:
Briefly HTTPS has 3 main benefits:
(b) Data integrity
None of these are provided by HTTP, thus if your Koha server is online, the SSL (HTTPS) is simply a must these day!
The Basics Explained
GoogleIndicTransliteration feature utilizes a Google API designed for phonetic input of several Indian languages by transliterating text written in English on the fly to its Indian language equivalent. For example, if you type “Rabindranath” and it is set to transliterate to Bengali, the software will automatically convert to “রবীন্দ্রনাথ” or say “Premchand” to “प्रेमचाँद” if set for Hindi.
How it works
GoogleIndicTransliteration system preference is set to “
Show” from the Koha staff client, the code inside the file
opac-bottom.inc loads up the API loader code available at
www.google.com/jsapi, which in turns provides the framework so that the actual transliteration code available in the file
googleindictransliteration.js can work its magic and provide the users with the transliteration feature.
Why does HTTPS break it but not HTTP?
Short answer: Mixed context!
Long answer: HTTPS is important to protect both your site and your users from attacks online. As of now, Koha code in
opac-bottom.inc calls the
jsapi code over HTTP, instead of letting the browser handle it correctly based on the security context (i.e. whether the page is being served over HTTP or HTTPS). So when OPAC is on HTTP,
jsapi is fetched over HTTP, things are on the same page. However, when the OPAC is served over HTTPS and
jsapi continues to be fetched over HTTP, all modern browsers will flag it as a security violation known as “MIXED CONTENT” and halts the loading of
jsapi, as seen in the screenshot below:
As a result,
googleindictransliteration.js has nothing to work with. End result, the
GoogleIndicTransliteration feature does not work anymore! Bingo! We’ve found ourselves with a Koha bug!
Present status of bug
There is a patch submitted to Koha Bugzilla against Bug 17103 – Google API Loader jsapi called over http, waiting for sign-off and QA. Once it clears Koha’s project governance processes, it is expected to get pushed to the master and then be released with a stable version of Koha. Once that happenes we won’t have this issue anymore.
NOTE: Expect this fix to get backported across the current supported older releases.
Your options until the patch is officially released
(a) Do without GoogleIndicTransliteration feature until the fix is officially released by the Koha project if you are using HTTPS
(b) Edit your “
opac-tmpl/bootstrap/en/includes/opac-bottom.inc” file. Find the following section:
Replace the protocol notifier “
jsapi URI with “
https:“and save the file. It should look like this after the change:
CAVEAT: If you are doing this edit, it is assumed that you know what you are doing. If you make any mistake and break something during this, its all on you.
ASSUMPTION: This edit assumes you are on Koha 3.18.x and later and is using a .deb package based installation on Debian or Ubuntu.