Category: Développement

Le CSRF , mais pourquoi faire ?

Imaginons, juste comme ça hypothétiquement, que vous vouliez désactiver de manière globale la protection CSRF sur la totalité des urls d’un site django.

Vous pensez qu’il suffit de désactiver le middleware qui va bien (soit django.middleware.csrf.CsrfViewMiddleware ) pour que op c’est bon, la vérification CSRF n’est plus mise en place ?

Vous serez alors décontenancé de voir que non, cela ne suffit pas. Il faut aussi ajouter le décorateur csrf_exempt ( qui se trouve dans django.views.decorators.csrf ) sur chacune de vos urls. Un peu compliqué en vrai, surtout si vous avez beaucoup d’urls. _

Comment faire ?

Tout simplement coder un middleware qui va l’enlever pour vous. Vous n’aurez ensuite qu’à le déclarer dans les middleware actifs.

class NOCSRFMiddleware(object):

def __init__(self, get_response):

        self.get_response = get_response



    def __call__(self, request):

        setattr(request, '_dont_enforce_csrf_checks', True)

        response = self.get_response(request)

        return response

Et voila ! Il suffit ensuite de le déclarer dans MIDDLEWARE et le tour est joué ( par exemple avec un  BadIdeaApp.BadMiddleware.NOCSRFMiddleware

Groupons, Groupons, Groupons !!!

J’avais totalement oublié l’existence du templatetags regroup qui permet de regrouper des objets identique par un attribut commun. Comme regrouper une liste de dictionnaires par les valeurs de l’un des attributs. La documentation complète est disponible ici : https://docs.djangoproject.com/en/4.2/ref/templates/builtins/#regroup

Et redécouvrir ce templatetags m’a été bien utile. Surtout en le couplant avec un autre templatetags que j’avais également oublié, dicsort ( https://docs.djangoproject.com/fr/4.2/ref/templates/builtins/#std-templatefilter-dictsort) qui va trier une liste de dictionnaire par une des clés des dictionnaires.

Je me suis retrouvé il y a quelques temps avec une problématique, remplacer une chaine par une autre dans un attribut CharField d’un model django.

La première possibilité était de faire tout simplement une belle boucle sur la totalité de mes instances de module, faire le remplacement en python et sauvegarder la nouvelle valeur.

Sauf que j’avais quasiment un million d’objet et que je n’avais pas envie que cela prenne des plombes. Et puis c’était un peu moche.

Du coup j’ai un peu fouillé et miracle, j’ai trouvé une solution que voici.

On commence par définir la fonction de remplacement, tout en django et en SQL.

from django.db.models import F, Func, Value

def replace_func(field_name, old_str, replace_str):

    return Func(

        F(field_name),

        Value(old_str), Value(replace_str),

        function='replace'

    )

Ensuite, il n’y a quasiment plus rien à faire. On va simplement appeler update sur tout les objets et utiliser replace_func.

Par exemple :

MonModele.objects.filter(CONDITIONS).update(

    champ_a_modifier=replace_func("champ_a_modifier",

                                  "str_que_lon_veut_remplacer",

                                  "nouvelle_chaine_de_caractere")

Et voila, c’est fini.

Longtemps que je n’avais pas posté de billets dans cette partie du blog. (Vous allez me dire longtemps que je n’ai pas posté de billet tout court, et vous auriez raison, mais ma bonne résolution de fin de vacances d’été est de changer cela).

Mais donc, pour reprendre doucement dans la partie technique, je vais commencer par partager un truc que tout le monde connaît sûrement déjà. Sauf que perso, j’oublie à chaque fois que cette fonctionnalité de django existe et donc je galère pour la retrouver. Du coup je me dis qu’en l’écrivant je finirais par la mémoriser (et donc en fait j’écris plus pour moi qu’autre chose, je suis un vilain !:) ).

Donc imaginons que vous avez un modèle. Truc assez classique. Ce modèle vous lui avez défini une représentation textuelle de base avec str . Sauf que vous avez plusieurs forms, donc certains ont des ChoiceFields utilisant ce modèle (Exemple un modèle User et vous avez un modèle Post où vous devez choisir le rédacteur du billet). Et manque de chance, vous avez besoin d’une représentation textuelle différentes de celle de base pour un de vos forms. Où même pire, vous avez besoin de plusieurs représentations textuelles différentes, pour plein de forms différents.

Vous êtes alors bien marri.

Mais en fait non, parce que Django vous fourni une façon à la fois simple et élégante de faire. A chaque fois que vous aurez besoin d’une représentation textuelle qui ne soit pas celle par défaut, il vous suffira de définir une classe dérivant de ModelChoiceField et qui implémentera la méthode label_from_instance. Cette méthode prend comme unique paramètre l’objet qui doit voir sa représentation textuelle définit et renvoie une chaîne de caractère.

Petit exemple tiré de la doc django :

Voilà. Aussi simple que cela. Vous n’avez plus qu’à utiliser votre classe fille de ModelChoiceField dans votre formulaire et le tour et joué.

Bonus, ça marche aussi pour les MultipleChoiceField, il faudra simplement définir une classe fille de ModelMultipleChoiceField

et le lien vers la doc qui parle de tout cela : (https://docs.djangoproject.com/fr/2.0/ref/forms/fields/)

Je me suis enfin lancé dans l’écriture d’une app django gérant les badges (ou les succès si vous préférez). L’objectif étant de pouvoir réécrire de zéro histoires de rôlistes. L’idée était de tenter de faire une vraie app django, en mode réutilisable, histoire que peut-être des gens puissent trouver intéressant de l’utiliser.

Je me suis retrouvé avec deux problèmes concernant mes tests :

• Souvent on gagne un badge quand on a créé suffisamment de chose (comme des checkin, des billets de blogs ou des contributions diverses). Sauf que je ne voulais pas créer dans mon app des models ne servant à rien, juste pour pouvoir en créer lors de mes tests.
• Je voulais pouvoir créer des badges se gagnant sur un critère du style ‘être venu un certain nombre de fois sur une URL.’ Donc mettre en place des décorateurs sur des vues. Mais là encore, je ne voulais pas avoir à créer des vues dans mon application rien que pour les tests.

Au final, en lisant un peu de doc, j’ai réussi à faire ce que je voulais.

Tester un décorateur sans créer des  vues inutiles dans son app.

Je savais déjà comment forger des requests avec la RequestFactory. Par contre pour créer des vues, je n’en avais pas la moindre idée.. Une petite question plus tard, Foxmask m’a indiqué un lien qui allait me donner la solution que je cherchais. (le voici) Il suffisait au final d’utiliser mock pour créer, directement dans mes tests, une fausse vue que j’allais pouvoir décorer.
Une dernière subtilité, comme vous le verrez dans le lien novapost (ou dans mon code), si vous utilisez wraps pour créer votre décorateur, il faudra ajouter l’argument assigned=available_attrs(view_func) à votre appel à wraps (tout comme django le fait). Cela sera nécessaire pour pouvoir utiliser votre décorateur en mode fonction, ce que vous devrez faire dans vos tests, à cause d’un bug python 2 (celui-ci :http://bugs.python.org/issue3445)

Créer des models uniquement pour les tests

Ici après quelques test infructueux, je suis finalement tombé sur ce ticket dans le track django. Dont le dernier commentaire remonté à 2 mois. Et en fait, l’astuce est toute simple. Il suffit de créer le model de test dans le fichier de test qui va bien (c’est ici au niveau de mon code) et ensuite de modifier manuellement une des migrations django pour ajouter la création du modèle, uniquement si on est dans le mode Test. Petite modification de mon cru comparé au code donné dans le ticket, j’ai fait en sorte que les models de tests soit créé si la base commence par test ou si elle est stockée en mémoire (mon code est ici).

Rien de bien merveilleux ou de bien révolutionnaire, mais bon, on ne sait jamais, ça pourrait peut-être être utile à l’un d’entre vous.

Vous êtes djangonautes ? Et vous n’avez pas encore acheté votre billet pour DjangoCon Europe ?

Alors peut-être que vous ne le saviez pas. Après tout, même si on a essayé de faire un maximum de com sur le sujet, on n’en fait jamais assez et il est fort possible que vous soyez passé à coté.

Donc, je vous refais un petit topo.

3 jours de confs du 13 au 15 mai et 2 jours de sprint le 16 et 17 mai. Et tout cela en France, donc facile au niveau transport, il vous suffit de prendre un TGV.

Mais surtout, surtout, ce ne sont pas trois jours de confs dans une simple salle de conf, aussi belle soit-elle.

Non, ce sont trois jours de confs (et 2 jours de sprint) dans une île. Oui, dans une ILE. L’île des embiez pour être exact, une petite île qui se trouve dans le Var qui appartient à la famille Ricard.

Imaginez donc la scéne. Vous sortez de votre TGV à Toulon, vous prenez un bus et vous arrivez sur un port, le port du Busc. Et la vous prenez un petit ferry et vous voguez, le doux soleil de méditerranée vous réchauffant les neurones.

Et puis après 10 minutes d’une aventureuse traversée, vous accosterez, tel Jim Hawkins, sur l’île des poneys ! Et vous n’en repartirez plus avant 3 (ou 5) jours. Parce que oui, quitte à faire des choses folles, on s’est dit qu’on allait aussi prendre en charge l’hébergement. Comme ça vous n’aurez pas à vous embêter à chercher un hotel proche des conférences, à pester parce que celui que vous vouliez n’a plus de chambre, etc etc, non tout est compris dans le billet.

Et puis on s’est dit que comme c’était sur une île, y il y avait donc des plages. Et que qui dit plage dit baignade. Et que votre conjoint(e) allait peut être vous en vouloir si vous partiez 3 ou 5 jours au soleil sans lui/elle. Donc il y a un forfait pour les accompagnant(e)s et les enfants aussi. Comme ça, vous pouvez même venir en famille.

En fait, la seule chose que l’on ne fournit pas, c’est la crème solaire. Pour le reste, que ça soit nourriture, vin, fromage, ou café, pas de problème. (Par contre, je suis désolé mais je crois que la pizza froide n’est pas au menu des repas… mais vous survivrez à 3 jours sans pizza froide hein ? Surtout si on le remplace par des poissons grillés à la plancha).

Bon après vous allez me dire que tout ça, c’est bien beau. Mais que des confs on y vient surtout pour les confs et pas que pour passer des vacances ; Et qu’il va falloir que le programme il secoue les cocotiers (par contre désolé, il y en a pas sur l’île des cocotiers) un peu, parce que sinon, autant aller à une conf php hein ..

Alors je vous dirais, que vu le programme que l’on vous a préparé, les cocotiers ils vont carrément se trémousser des racines jusqu’au noix de coco. Parce qu’il n’y a vraiment que du bon (et là ce n’est pas l’organisateur qui parle mais le djangonaute impatient).

Vous voulez comprendre à quoi sert App Loading ? (une des nouveautés de la future version). Ca tombe vraiment bien parce qu’Aymeric Augustin vous en parlera pendant une keynote qui s’annonce captivante. Vous faites de l’ecommerce et vous utilisez django-oscar ou vous voulez l’utiliser ? Vous êtes vraiment chanceux, le créateur de django-oscar sera là. Il vous le présentera et bien entendu vous aurez trois jours pour discuter avec lui. Et en plus, comme personne ne quitte l’île, vous êtes sur de ne pas le rater. Il sera forcément là, sur l’île, avec vous ! Et là, je ne vous parle que de deux conférences, mais je pourrais aussi vous parler de Meghan qui va nous parler de expérience utilisateur, de Christophe pettus, de Jacob Burch et Kaplan Moss qui vont disséquer Django, de Julia qui parlera RAD et Django, d’Angel qui mixe Jeux vidéos et REST, etc etc .. Mais je ne vais pas non plus vous faire un copier coller de la page programme, je vous ai donné le lien, vous pourrez juger par vous même et voir quelles seront les confs qui vont vous faire dire ‘Whouaaaa, il faut que j’y sois’.

Donc récapitulons ensemble  :
– un super lieu juste totalement fou (vous voulez des photos, allez en voir ici !! )
– un super programme
– des confs qui sont à la fois des confs et des vacances ( je vous ai dit qu’il y avait une piscine aussi ? Et un sauna ? En accès libre pour les conférenciers ? Non parce que je suis pas sur de vous l’avoir dit)

Maintenant la question que je me pose c’est : Si vous n’avez pas encore votre billet, pourquoi vous perdez du temps à me lire ? Foncez, les ventes seront stoppées le 20 avril au soir !!!

Ha, je pourrais dire aussi que ça sera l’occasion de voir une tripotée de Djangonautes, français ou pas ; l’occasion donc de refaire le monde du développement web une fois de plus, le soir, un verre de ricard (avec ou sans alcool) à la main tandis que le chant des cigales nous bercera doucement.

Non mais vous êtes encore là ? J’espère que vous avez votre ticket alors !!!

Ce week-end avait lieu la première DjangoCon Toulouse, une rencontre django régionale au pays du cassoulet. Les festivités commençaient à 11h30 le samedi avec des LT, puis une rafale de huit conférences l’après midi, et pour finir sprint et ateliers le dimanche.

Cette Djangocon est également la première Cong qui n’était pas un événement autonome mais un événement à l’intérieur d’un autre événement (à savoir le capitole du libre). Je dois avouer que je suis assez partagé sur cette solution de l’événement dans l’événement. Effectivement cela permet d’attirer ‘des curieux’ qui viennent papillonner le temps d’une conférence ou d’un atelier (le nombre de 64 personnes dans l’auditoire a d’ailleurs été atteint). Cela permet aussi d’assister à une conférence de Jérémie Zimmermann la fin du premier jour. Enfin, cela permet de diminuer la charge de travail pour les orgas. Mais cela aussi signifie ne pas être mettre de tout les choix (essentiellement logistique) et de devoir gérer les interactions avec l’organisation globale. Je suis donc partagé sur ce mode d’événement à l’intérieur d’un autre.

Mais venons en maintenant au Djangocon en elles mêmes. Tout d’abord le programme. LT et conférences étaient très intéressants. La rafale de huit conférence l’après midi, conférence de 20 minutes plus 5 minutes de questions auraient pu être difficile à encaisser mais les conférences étant intéressantes et les orateurs d’un bon niveau, tout est passé comme une lettre à la poste.

Étonnamment, les ateliers et sprint du dimanche matin furent même plus productif que ce à quoi je m’attendais. Et l’organisation ‘au dépoté’ (en tout cas ce n’étais pas indiqué dans le programme) d’un atelier d’initiation était une excellente idée. Cela confirme à nouveau mon sentiment qu’il y a une forte demande concernant des initiations à Django et que c’est des choses que les ‘anciens’ de la communauté, les sachants, doivent mettre en place pour partager leur connaissance et jouer le rôle de ‘mentor’.

Alors effectivement, il y a, à mon sens des choses améliorables au niveau logistique, comme l’approvisionnement en jus de fruit / café / eau ou le repas/soirée du samedi soir, mais ce n’est pas si grave que cela (et on revient à mon premier point, le fait de s’intégrer dans un événement plus grand).

Les points positifs importants que je retiens de cette conférence sont :

• avoir des conférences non totalement centré sur Django est une excellente chose. À Rennes il y avait une conf sur cherrypie et circus, à Toulouse une conf (différente de celle de Rennes) sur circus aussi et ça permet d’ouvrir un peu ses œillères.
• Les ateliers débutants sont des choses à mettre en place. Se pose la question de les mettre en place dans des Djangocongs d’une taille plus importantes.
• La soirée du samedi soir est un point très important, de mon point de vue. Les soirées jeux de plateau remportent mes suffrages, pour l’instant.
• Sprint et ateliers le dimanche matin peuvent être efficaces. Peut-être que la solution est d’en décaler leur démarrage en prenant en compte le besoin de sommeil.

Ces Djangocon sont à mon sens un beau succès et j’ai vraiment été très heureux d’y être. Je profite de ce billet pour, à nouveau, remercier les organisateurs et les orateurs. (Et ce fut assez rigolo de se rendre compte qu’il y avait des ponts très intéressant entre les 2 djangocon Rennes et Toulouse, comme par exemple  une présentation de tastypie à Rennes, suivi d’un atelier Tastypie à Toulouse ).

Samedi 17 novembre c’était donc la première edition des DjangoBreizh, une rencontre django locale en bretagne organisé par Exirel (bon ok, je ne suis pas tout a fait breton et pourtant j’y étais mais j’étais une exception) Le programme se découpait ainsi :

• matin conférence
• début d’après midi LT
• reste de l’après midi barcamp ou atelier d’initiation

Pour une première conf, et conf régionale qui plus est, je trouve que le public fut au rendez-vous. 27 personnes pour les conférences, c’est en effet une belle réussite. Pour l’occasion, la cantine numérique de Rennes avait prêté ses locaux toutes la journée, ce qui a permis de mettre en place les conférence du matin et l’atelier initiation du matin (les barcamps se passant à quelques dizaines de mettre à la maison des associations)

Ce que je retiens de cette rencontre régionale (hormis le fait qu’à rennes, il pleut tout le temps) c’est :

• il peut être difficile d’avoir des conférenciers locaux, il suffit alors de les faire venir d’ailleurs (mais il y a eu un certain nombre de conférencier ‘du cru’ et ça fait plaisir)
• la partie barcamp est une partie toujours très intéressante et qui fonctionne vraiment bien
• l’atelier d’initiation était une première, jamais encore cela n’avait eu lieu dans une rencontre django. Le public était restreint (6 à 8 personnes) mais j’ai l’impression que c’est un format qui fonctionne et qui réponds à une vrai demande des gens, un vrai plus de cette édition bretonne, et qu’il faut, à mon avis, répliqué, à minima, dans les autres éditions régionales.
• Lors des djangocong 2012, certains pensaient que les rencontres régionales allaient ‘faire se relâcher la pression sur la conférence nationale’. A priori, si je généralise à partir de l’exemple de cette première conférence régionale, c’est l’inverse qui va se passer. Les gens qui ‘goûtent’ aux rencontres django régionale, dés qu’ils apprennent qu’il y a des ‘grosses rencontres’, veulent absolument y aller.
• Le soir c’était free style, une bonne partie des gens se sont retrouvés dans un bar à jeux pour siroter une bière en jouant à des jeu de plateau. Et ce fut excellent. Le format bire et jeu de plateau testé pour la première fois en 2011 montre encore une fois qu’il est un excellent format (voir le meilleur) en ce qui concerne les soirées post conférences (ou inter pour des confs de 2 jours).
• J’avais peur que les rencontres régionales ne soient que des espèces de mini grandes djangocong, avec uniquement des ‘vieux’ djangonautes présents. Ce ne fut pas le cas et c’est tant mieux.

En résumé, ce fut une excellent première édition et j’ai hâte de voir ce que donnera la deuxième édtion (si il y en a une).

En tout cas merci à Exirel d’avoir organiser tout cela, à la cantine numérique de Rennes d’avoir participé à l’aventure des django en bretagne, aux auditeurs d’être venus faire des conférences de qualités et aux rennais d’avoir répondu présent.

Et à la semainse prochaine pour DjangoCassoulet à Toulouse !!!!! Espérons qu’il y aura des pains au chocolat !

Lors du Django Meetup Paris numéro 2 (qui a eu lieu dans les locaux de 20 minutes, merci à eux pour le prêt de la salle (et à Julien pour l’orga) ), un petit récap des confs EuroDjango a été fait par Samuel (le frère de David, et oui un Paccoud peut en cacher un autre!!). Apparemment un des sujets porteur des EuroDjango avait été le ‘web temps réel’ (ce que je déteste ce terme tiens … temps réel, ça a un sens.. ça ne veut pas juste dire un truc en mode connecté) et la mise en place de celui ci dans Django (et du fait que peut être notre framework adoré n’était pas super en avance sur ce sujet).

J’en ai profité pour donner mon avis sur la question. A savoir qu’à mon sens, les serveurs webs n’était pas fait du tout pour gérer des connexions en mode connecté. Parce qu’ils n’ont pas été prévu pour cela. Idem pour le cœur de django qui n’est pas fait pour garder des pools de sockets, des états par connexion clientes, etc etc …

Alors qu’à contrario il y a des frameworks (je pense à twistted mais pas seulement) ou des manières d’écrire des serveurs qui permettent de gérer proprement des communications en mode connectées.

Il me semblait donc logique de ‘sortir’ la partie websocket du cœur de Django pour qu’elle soit gérer par ‘autre chose’. Il me semble qu’à la fin de ma tirade explicative, quelqu’un m’a dit ‘ben ok, fait le’ (me demande même si ce n’est pas ce fourbe de n1k0)

Du coup, ben ayant eu un peu de temps, ces jours-ci, j’ai rapidement fait un proto merdique de test.

Le principe a été de prendre l’exemple de simple chat de Gevent-SocketIO et de le ‘transformer’ en une commande de management Django. La commande de management simulant un serveur de gestion des connexions socketIO des utilisateurs. Du coté django, on a une première vue qui demande de donner un nickname puis on se retrouve sur la fenêtre de chat (qui utilise socketIO) et on peut discuter avec les autres connectés. J’ai rajouté deux petits trucs, pour le plaisir, le fait d’avoir les 5 dernières lignes de discussion (ça se récupère par la partie WebSocket) et le nombre de user et lignes de discussions totales (s’affiche la première fois par la connexion HTTP classique, se met à jour par les WebSocket)

Il faut donc à un moment ou un autre, lier la partie DjangoWeb de la partie SocketIO. Comme ce n’est qu’un prototype pour m’amuser, je passe à la vue de chat une key généré aléatoirement, key que me renvoie le client JS à travers la websocket.

Bon, bien entendu, tout cela n’est qu’un prototype pour expliquer (avec du code) la manière dont je voyais les choses. Bien entendu bis, il faudrait ‘lier’ la partie Web classique et Websocket d’une meilleure façon, ne pas utiliser une commande de management brute de décoffrage, potentiellement  élaguer pas mal gevent-socketio pour enlever tout ce dont on n’aurait pas besoin, etc etc …

Mais voilà, j’avais juste envie de faire un test, d’en parler ici et de vous demander votre avis sur la question:)