ODOO 8 – accès mixte http/https au CMS et au Back-Office (2/2)

!! mise à jour le 04/12/2014 !!

L'objectif est d'accéder au CMS en http et au Back-office en https.
Cela permet :

  • d'éviter d'acheter un certificat ssl pour l'accès des internautes au CMS
  • d'accéder en https au Back-Office grâce à un certificat ssl auto-signé et gratuit 

Après avoir réalisé plusieurs tests, j'arrive à la conclusion qu'il est très difficile de trouver une configuration Nginx réellement opérationnelle.
Même si on y arrivait, elle serait extrêmement sensible à toute évolution ultérieure de Odoo.
Cela conforte donc la remarque de SISalp concernant cette "fausse bonne idée".
Je déconseille donc désormais cette solution !!

Environnement technique
- serveur virtualisé Debian 7.3 (wheezy) sur lequel est installé ODOO
- navigateur sur PC Linux Mint 14  à partir duquel on accède à ODOO

Description 

Se connecter sur le serveur debian avec les droits "root"
- installer nginx
apt-get install nginx

- créer les clés ssl
mkdir /etc/nginx/ssl
cd /etc/nginx/ssl
openssl genrsa -des3 -passout pass:x -out server.pass.key 2048
openssl rsa -passin pass:x -in server.pass.key -out server.key
rm server.pass.key
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

- créer le fichier de configuration
 vi /etc/nginx/sites-available/votre_site.com

... avec le contenu suivant (désormais déconseillé) :

upstream odoosrv {
    server 127.0.0.1:8069;
}

server {
    listen      80 default;
    server_name votre_site.com www.votre_site.com;
    access_log  /var/log/nginx/odoosrv.access.log;
    error_log   /var/log/nginx/odoosrv.error.log;



    location ~ ^/(sitemap.xml) {
        root /var/www;
    }
    location /website/static/ {
        proxy_cache_valid 200 60m;
        proxy_buffering on;
        expires 864000;
        proxy_pass http://odoosrv;
    }
    location /web/static/ {
        proxy_cache_valid 200 60m;
        proxy_buffering on;
        expires 864000;
        proxy_pass http://odoosrv;
    }
    location /web/login {
        rewrite ^/.*$ https://$host$request_uri? permanent;
    }

    location /web/database/ {
        rewrite ^/.*$ https://$host$request_uri? permanent;
    }
    location / {
        proxy_pass  http://odoosrv;
    }
}

server {
    listen      443;

    server_name votre_site.com www.votre_site.com;

    ssl on;
    ssl_certificate     /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
    keepalive_timeout   60;

    ssl_ciphers             HIGH:!ADH:!MD5;
    ssl_protocols           SSLv3 TLSv1;
    ssl_prefer_server_ciphers on;

    proxy_buffers 16 64k;
    proxy_buffer_size 128k;

    location /web/static/ {
        proxy_cache_valid 200 60m;
        proxy_buffering on;
        expires 864000;
        proxy_pass http://odoosrv;
    }

    location ~ /. {
        proxy_pass  http://odoosrv;

        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_redirect off;

        proxy_set_header    Host            $host;
        proxy_set_header    X-Real-IP       $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto https;
    }

    location /page {
    return 301 http://$host$request_uri;
    }

    location / {
    return 301 http://$host$request_uri;
    }
}

- créer le lien symbolique
ln -s /etc/nginx/sites-available/votre_site.com /etc/nginx/sites-enabled/votre_site.com

- relancer nginx
/etc/init.d/nginx restart

N'étant pas spécialiste de Nginx, je suis preneur de toute proposition d'optimisation du fichier précédent. Merci d'avance.

*** Pour sécuriser un  site en production, il faudrait protéger beaucoup plus les accès au back-office :

  • en interdisant (via firewall) tout port autre que 80 et 443
  • en demandant une authentification supplémentaire sur le serveur web pour le port 443
  • en interdisant l'accès à la location /web/database/manager qui permet d'administrer les bases
  • etc ...

*** exemple de sitemap.xml à ajouter sous /var/www
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
    <url>
        <loc>http://www.agipme.fr/website/info</loc>
    </url>
    <url>
        <loc>http://www.agipme.fr/</loc>
    </url><url>
        <loc>http://www.agipme.fr/page/aboutus</loc>
        <lastmod>2014-11-20</lastmod>
    </url><url>
        <loc>http://www.agipme.fr/page/actualites</loc>
        <lastmod>2014-11-20</lastmod>
    </url><url>
        <loc>http://www.agipme.fr/page/a-propos</loc>
        <lastmod>2015-01-02</lastmod>
    </url><url>
        <loc>http://www.agipme.fr/page/blog</loc>
        <lastmod>2015-01-08</lastmod>
    </url><url>
        <loc>http://www.agipme.fr/page/contactus</loc>
        <lastmod>2014-12-05</lastmod>
    </url><url>
        <loc>http://www.agipme.fr/page/faq</loc>
        <lastmod>2015-01-03</lastmod>
    </url><url>
        <loc>http://www.agipme.fr/page/mention-legale</loc>
        <lastmod>2015-01-08</lastmod>
    </url><url>
        <loc>http://www.agipme.fr/page/odoo</loc>
        <lastmod>2015-01-09</lastmod>
    </url>
</urlset>

2 réflexions sur « ODOO 8 – accès mixte http/https au CMS et au Back-Office (2/2) »

  1. Merci pour cet article qui propose une solution originale.

    Le but est donc d'utiliser un certificat non officiel sans créer d'alerte au niveau du navigateur du simple visiteur parce que les informations du cms sont publiques et n'ont pas besoin d'être cryptées.

    Je ne l'ai pas encore testée, mais j'ai une question et un commentaire relatif au cas d'usage.

    La question : cette solution garantit-elle qu'une information qui doit être cryptée n'est pas transmise en clair ? Je pense à un transfert de document par exemple depuis une url par un utilisateur déjà authentifié et donc sans repasser par la case login.

    Le commentaire sur le cas d'usage : On doit éviter d'exposer son ERP à internet si on peut s'en passer. Publier des pages statiques ne le justifie pas à mon avis, autrement dit pour publier des pages http, n'utilisez pas l' ERP de votre société.

    Exposer l'ERP n'est envisageable que si cette fonction cms est intégrée à une solution e-shop ou autre fonction nécessitant une authentification. Mais dans ce cas, le cryptage est nécessaire et un certificat valide est préférable. Et si on a un certificat valide, il vaut mieux l'utiliser pour l'ensemble du site.

    Merci encore pour le contenu de ce site
    my 2cts

    SISalp

    1. @ SISalp

      1- Je ne peux pas répondre à ta question car mes tests ont été insuffisants.

      2- Je suis complètement d'accord avec toi concernant ton commentaire :
      – si fonctionnalité uniquement de CMS alors back-office uniquement limité à l'administration du site et non pas à des fonctions métier. Prévoir une autre instance Odoo pour cela.
      – si e-shop, alors acheter un certificat SSL et le déployer sur la totalité du site

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *