24 Feb 2016, 09:30

Around the Web - February 2016 - MySQL, Docker, Security & Webapps/API



  • Official images are to move from Ubuntu to Alpine : main arguements are about disk space saving (and so bandwith and time to launch a container) and security (lower surface of attack).
    • "Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox" according to the site
    • First, I was sceptical as it requires the whole ecosystem to move from ubuntu to alpine ; indeed, wether you like it or not, people are used to ubuntu/debian and other mainstream distribution and all packages we are used to have are not yet available in alpinelinux also. To be honest, main packages are available.
    • Then, a debian or whatever base image will still exist, be safe with that ; however, if you want to "hack" / inherit from a docker base image, you'll have to switch to Alpine.
    • Third, we could consider that once your docker host has the base image in cache, the ~180M size of base image is not an issue. But starting from 5M may be a good argument however.
    • Starting testing it on ARM device and especially Raspberry Pi, I'm quite pleased with its reactivity and packages available.
  • Some tips to reduce the size of your docker image and also understand how size and layers impacts your docker image. Following the instructions, I could reduce my influxdb-chronograf docker image by 70M approx (from 360 to 290M if I'm correct)

Security & API/Web App


26 Feb 2013, 21:51

Browser : Same Origin Policy & CORS

The same origin policy for Javascript is defined as follow :

The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin.

And regarding "origin" : Two pages have the same origin if the protocol, port (if one is specified), and host are the same for both pages. The following table gives examples of origin comparisons to the URL http://store.company.com/dir/page.html:

https://store.company.com/secure.htmlFailureDifferent protocol
http://store.company.com:81/dir/etc.htmlFailureDifferent port
http://news.company.com/dir/other.htmlFailureDifferent host

For security reason, it's obvious to understand that it's not allowed. However, sometimes you may need to interact with data hosted elsewhere in the browser :

  • Display a menu hosted elsewhere (as we do for Globe where the menu is hosted on CMS side but also displayed on DMS side)
  • You may want to aggregate several RSS Feeds coming from different services in a single page, by using some ajax code
  • ...

You can do it by embedding some content from a given domain into another one (like image, video, some scripts, etc) but as soon as you have ajax/ XmlHttpRequest, you are in the same origin policy and you are blocked, till you discover CORS (Cross Origin Ressource Sharing) which provides a way for web servers to support cross-site access controls, which enable secure cross-site data transfers. You can use CORS for :

If from a DomaineA.com you need to fetch data from DomaineB.com, you will then need :

  • On DomaineB.com to add some Access-Control-* headers in your page to define who can safely pull your data
    • Access-Control-Allow-Origin : authorised hosts list or * if you authorise all hosts.
    • Access-Control-Request-Method : Get / Put / Post / Delete
    • Access-Control-Request-Headers : if you want to check against given headers
    • Access-Control-Allow-Credentials : if you want credentials to access your data
    • ...
  • If you don't do this, no way to fetch data from DomaineB.com - your browser will block you when you are on domaineA.com.

Once you enabled cors on client/server side, you can then safely fetch data from domaineB.com in your page hosted in domaineA.com ; nice isn't it ?

The main limitation for me so far is that you can use CORS only if you manage DomaineB server or have contact with domaineB owner, otherwise, you cannot do anything as you will not be granted to fetch data from their servers. Thus alternatives are :

  • Use a reverse proxy on domaineA.com to make the remote resource being seen as a local one to bypass same origin policy and not requiring CORS being enabled (I just did that for a pet project)
  • Go back to a initial backend treatment which will fetch the remote data to alllow you to consume it locally
  • Bypass it with other techniques your favourite language may provide

So even if CORS is a nice idea and a W3C recommendation, seems not mature enough and/or too much complex (unless you can manage the whole chain) to be used effectively on a public side. However for internal projects, it can make sense.