- Datamith, convertisseur de base de donnée
Je viens de publier Datamith, un framework ruby permettant de convertir des base de données MySQL.
L’idée est de permettre de définir des règles de conversion pour importer le contenu d’une base de données dans une autre.
- Qu’est-ce qu’un serveur?
Lors d’une discussion récente, un ami m’a suggéré qu’un de ses problèmes de fonctionnalités disparaissant d’une application web venait du fait qu’il testait cette application sur sa machine locale plutôt que sur son serveur, en pensant que cette application désactivait ces fonctionnalités si elle repérait être sur une machine locale.
Bien que toutes sortes idées viennent immédiatement à un développeur pour réaliser cela lorsqu’on lui suggère, deux objections se présentent instantanément :
- Ça n’a aucun intérêt.
- Rien ne différencie un serveur d’une machine locale.
C’est ce second point que je voudrais clarifier aujourd’hui.
- Vous suivez vos visites effectives. Suivez-vous vos visites ratées?
Dans le domaine de l’analyse des visites, nous possédons de très bons outils. Beaucoup ne jurent que par google analytics, j’ai déjà présenté piwik, un autre outil de la même classe.
Mais si vous suivez à la trace vos visites réelles, qu’en est-il des visites qui ont été tentées alors que votre site était aux abonnés absents?
- mysql : hardcoder un mot de passe ou non?
L’automatisation de tâches nécessitant un mot de passe est souvent un dur dilemme en matière de sécurité. J’aimerais bien que mes utilisateurs puissent lister le contenu de telle ou telle base de donnée, mais je ne veux pas qu’ils aient le mot de passe.
De la même manière, on nous conseille généralement d’utiliser les mots de passe les plus cryptiques possibles (ce que je ne conteste pas). Le mot de passe est le sésame magique déplaçant les montagnes pour permettre l’accès à votre jardin secret. Mais peut-être qu’on se concentre justement trop sur le mot de passe lui-même, en oubliant ce qu’il y a derrière. À quoi donne accès ce mot de passe? C’est là la vraie question.
Mysql possède un système de gestion des autorisations très précis. Il est tout à fait possible de créer un utilisateur qui n’aura que le droit en lecture sur une seule table, voir une seule colonne :
grant select on supersecret_db.public_read to "user"@"localhost" identified by "user" ;
Vous pouvez aussi bien n’autoriser que select et update, ce qui permettra à cet utilisateur de lire et modifier des entrées, mais pas d’en créer. Vous pouvez dès lors écrire le login et le mot de passe en plain text dans un script, il n’y a plus de risques.
Je vous renvoie à la documentation officielle pour plus d’informations.
- Un apprenti cracker vous ennuie? Dites-le lui!
Si vous avez un serveur dédié et que vous consultez vos logs, vous voyez inévitablement apparaître des attaques. Il y en a tous les jours, et ce n’est pas bien grave tant qu’on maintient son système à jour, mais c’est toujours agaçant. Ce que je vous propose aujourd’hui, c’est une manière de répliquer. Cela ne fonctionne pas toujours, mais c’est toujours une grande satisfaction d’imaginer la réaction de celui qui croyait attaquer en tout anonymat lorsque cela fonctionne.