HTTPS and Websites

I nearly forgot – after i posted the article about „enabling https“ a few days ago, there are of course some other problems that may come up.

Like the fact that – until recently – no one really cared about making the site itself… well… „https-proof“. Most common is that some resources may be missing, or a warning may be displayed (depends on your browser) – most common, i.e. in chrome you will encounter a warning sign in the adress bar, or even a red striked-through „https“ before the URL. Well, no-one said it would be THAT easy.
So, how to deal with that?

Internal Resources

This refers to all your internal lings and resources – like images, css… every resource you host on your own.
In fact, this is the easiest to come by, because you know you have a working certificate and https-enabled webserver. I’ll make a guess and say, whenever you’ll set a link (or load a resource), you start with something like

<a href="http://....
<img src="http://...

Now, exactly that is it what keeps you away from a green lock in your browser. As simple as it is: forget about giving the protocol! Just let the browser decide…

<a href="//"...
<img src="//"...

This lets the visitors browser decide how to get the resources – usually the same way as the site was called.

It can be a pain to work over a large site, but on the other hand, there are enough tools for search and replace.

Somewhat more difficult may be the various

External Resources

Well, if you just have something like google analytics on your site, or you display youtube videos – don’t worry, google is (and usually all big players are) capable of handle that. Just test it.
However, there are more than enough examples for „web-services“ (usually displaying small snippets of information in form of a kind of widget) that don’t care about https. Simple test, call the resource via browser, once via normal http, once via https. If it works, just omit the protocol as above.
If not, unfortunately, there is no (simple) way to get this task done, but well – let’s see:

Looking for another service

Yep. Thats the easiest way. If there *are*, in fact, other services fitting to your needs. Get the code snippets, and test like before. If you can call the resource via https, all’s good. If not – search on.

Trick around the limitation

Well, you may stick to a service (or you may have no alternative), so that you’ll have to do a workaround. If you should do so or not, that’s up to you…
There’s really nothing preventing you to code a routine, getting the resource you want, save it locally to the server and then serve it as usual.

The advantage is obvious – if YOU serve the resource, it’s via an encrypted session. And, depending on how often you need to refresh the source, you may spare a whole lot of external calls (in fact, i do so with the geocaching pic on the right. Once a day i’ll get the (generated) picture via cron, and call it like any other pic).

The disadvantage is also clear – for once, your server has to contact the other server with a normal – unencrypted – http-request, and for second, if you need that resource on a per-user-basis (i.e., bound to the local time of the user, or username), it’s slowing down a lot. You have the call, you have the write-read-cycle of the server, and then the resource is sent to the users browser. Quite ineffective.

So, in my opinion, version 2 is for resources you need on just a daily basis or the like. If you end up doing requests on per-user-basis… get another service. Really. Or don’t serve the resource at all.

A small and basic example for a script:

wget -O /var/www/images/stat.jpg

Über Alariel

Seit diversen Jahren Systemadministrator im Bereich Linux, noch länger passionierter Rollenspieler, Reenactor und überzeugter "Heide". Nebenbei noch Tätig im Bereich der Webseitengestaltung, ob nun einzelne Seiten oder auch mehr.
Dieser Beitrag wurde unter Admin-Stuff abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.