Le TwiBlog

The one with Twidi

Aller au contenu | Aller au menu | Aller à la recherche

lundi 16 mai 2011

Dotcloud, django and auth_basic : exclude a file or a path from authentication

I'm currently developing a website in django (more precisely with satchmo) which is hosted on dotcloud for the development version.

To protect this site, i easily set a "basic authentication" by creating a nginx.conf (documented here and more specifically here) site with these lines :

   auth_basic "Dev version : restricted access";
   auth_basic_user_file /home/dotcloud/current/.htpasswd;

But later i encountered a problem with Paypal and it's "Instant payment notifications" system... because the site is protected and always returned a 401 http error to Paypal.

When i figured out this mess (not as quickly as i hoped...), i decided to remove the authentication for the "ipn" page in my site, while keeping it on the rest of the site.

So i laughed "ah ah easy to do !" and tried this :

   location / {
       auth_basic "Dev version : restricted access";
       auth_basic_user_file /home/dotcloud/current/.htpasswd;
   }
   
   location ^~ /shop/checkout/paypal {
       auth_basic off;
   }

But then, at the end of the "dotcloud push myapp.dev ." command, a little error message came to me

   Reloading nginx configuration: [emerg]: duplicate location "/" in /home/dotcloud/current/nginx.conf:1

So i checked the main nginx.conf file in my dotcloud serveur ("/etc/nginx/nginx.conf" and "/etc/nginx/sites-available/default", after a "dotcloud ssh myapp.dev") and, of course, i saw an existing "location /" block.

But... the dotcloud team gave us a chance to arrange this problem, by letting us having a uwsgi.conf in our project, which will be included into the existing "location /" block.

So, now i have two files :

nginx.conf :

   auth_basic_user_file /home/dotcloud/current/.htpasswd;
   
   location = /shop/checkout/paypal/ipn/ {
       auth_basic off;
   }

uwsgi.conf :

  auth_basic "Dev version : restricted access";

But this is not working. I now have a 404 http error on the "ipn" page. I don't know how nginx works but i think that it's because wsgi is not configured for this page. So, by duplicating the wsgi part of the "location /" block into mine, it seems ok (no need to touch uwsgi.conf, it's ok with only the auth_basic line):

nginx.conf:

   auth_basic_user_file /home/dotcloud/current/.htpasswd;
   
   location = /shop/checkout/paypal/ipn/ {
       auth_basic off;
       uwsgi_pass   unix:///var/dotcloud/uwsgi.sock;
       uwsgi_param SCRIPT_NAME /;
       uwsgi_param UWSGI_SCRIPT wsgi;
       include        uwsgi_params;
   }

And NOW, it works :)

I really found this to "hard" for a so simple thing... maybe i do not understand well how to do this. There is a way to avoid the duplicate configuration between the two location blocks ? If youi have the answer, and/or a better way to do this, comments are opened !

PS : Be reading the main nginx.conf i noticed that it's not just our own nginx.conf and uwsgi.conf which are included, but *nginx.conf and *uwsgi.conf.

PPS : thanks to django, satchmo and dotcloud teams. Great tools !

mercredi 20 février 2008

Ignorer automatiquement certaines extensions dans subversion (.pyc de python, .*.swp de vim...)

A chaque svn status il n'est pas rare de voir un certains nombres de fichiers "temporaires" qui ne nous intéressent pas, et que nous aimerions bien voir disparaître définitivement.

Alors il existe bien sur la commande svn propset svn:ignore "*.pyc" le_rep mais il faut non seulement le faire pour chaque projet, mais en plus pour chaque répertoire.

Une solution plus simple, et globale, consiste à dire à svn de toujours ignorer les fichiers qui ne nous intéressent pas, ce dans notre fichier de configuration $HOME/.subversion/config (dans la section miscellany) :

global-ignores = *.pyc .*.swp

lundi 27 mars 2006

Un portable, plusieurs réseaux, sous Linux (debian / ubuntu)

J'utilise chez moi et au travail le même pc portable (que je trimballe, mais c'est pas lourd, ca fera l'objet d'un autre billet).

Or bien sur les réseaux sont différents

  • à la maison, wifi protégé en dhcp
  • au boulot, reseau ethernet sans dhcp
  • au boulot toujours, quand le reseau marche pas, le wifi du voisin, dhcp, non protégé

Le soucis : a chaque fois jouer avec les ifup, ifdown, changer le resolv.conf (car le dhcp ecrase le fichier, et le reseau sans dhcp a besoin qu'on spécifie les dns)

L'envie : une simple commande très courte à taper à chaque fois que j'ai besoin de changer de reseau.

La solution : deux paquets (debian) à installer : ifscheme et resolvconf

ifsheme se charge de gérer des profils réseaux. Quant à resolvconf, il se charge de gérer, comme son nom l'indique, le fichier resolv.conf

Configuration :

Auparavant, j'avais une zone du type "iface eth0 inet static" et une "iface ath0 inet dhcp" (ath0 c'est mon interface wifi), avec des lignes commentées, que je modifiais pour chaque changement. En effet, je trouvais ça plus rapide que d'utiliser les outils de gnome/kde pour gérer les profils réseaux. Et j'avais un fichier "resolv.conf.taf" que je copiais à la place de resolv.conf dès que j'arrivais au boulot.

Maintenant, voici ce que j'ai dans mon fichier /etc/network/interfaces (je saute le début du fichier concernant l0, et je remplace les infos (ip, cle...) par des lettres) :

mapping eth0
        script ifscheme-mapping
  
iface eth0-taf inet static
        address 192.168.xxx.yy
        netmask 255.255.255.0
        gateway 192.168.xxx.1
        dns-nameservers aa.bb.cc.dd ee.ff.gg.hh

mapping ath0
        script ifscheme-mapping
 
iface ath0-taf inet dhcp
  
iface ath0-home inet dhcp
        wireless-essid MONESSID
        wireless-key MACLEWEP

On le voit, pour eth0, je ne gère que le scheme (profil) "taf", alors que pour ath0 (wifi), je gère "taf" et "home". Les profils sont gérés par carte, en spécifiant interface-scheme, donc ath0-taf et ath0-home sont deux profils totalement séparés.

On remarquera la ligne dns-nameservers pour eth0-taf, où l'in indique les dns. Cette ligne est inutile pour les profils wifis car ils sont en dhcp.

Pour utiliser ces profils, il suffit d'utiliser en premier lieu la commande ifscheme nom-du-scheme, suivi du ifup de l'interface voulue.

Par exemple : ifscheme home; ifup ath0

C'est déjà très bien. Mais pour moi, cela faisait trop à taper.

Je me suis donc créé un petit script, que j'ai appelé "n" (pour network) et que j'ai placé dans mon répertoire ~/bin (répertoire placé dans le path grace à une configuration de mon bashrc).

Voici ce script "n"

#!/bin/sh

case "$1" in
        taf)
                sudo ifdown ath0
                sudo ifscheme taf
                sudo ifup eth0
        ;;

        taf2)
                sudo ifdown eth0
                sudo ifscheme taf
                sudo ifup ath0
        ;;

        home)
                sudo ifdown eth0
                sudo ifscheme home
                sudo ifup ath0
        ;;

        *)
        echo "Usage: n {taf|taf2|home}"
        exit 1
        ;;
esac

L'utilisation est alors ultra simple

  • n taf quand j'arrive au boulot
  • n taf2 quand je préfère utiliser la connexion wifi du boulot
  • n home quand j'arrive chez moi

C'est très simple et rapide.

Bien sûr, il existe d'autres solutions, notamment la reconnaissance et configuration/choix automatique du réseau (hotplug et consors), le choix du profil par interface graphique...

Je vous met ici ce qui m'a mis sur la piste de resolvconf et ifscheme, et qui propose tout un tas d'autres solutions : Banc d'essai : Un portable, plusieurs reseaux (probleme classique)

PS : pour faire marcher resolvconf, j'ai du effectuer une action lue dans la doc : remplacer le fichier /etc/resolv.conf par un lien symbolique vers /etc/resolvconf/run/resolv.conf