Babozor’s Blog

Source: http://ajaxian.com/archives/zephyr-ajax-mvc-framework-for-php

Zephyr: Un Framework Ajax MVC pour PHP

Zephyr est plutôt un nouveau Framework MVC-Ajax pour PHP. Il est construit sur le moteur de templates Smarty, DAL Data Access Layer, CPAINT remoting framework, et la librairie JavaScript Prototype.

Le projet est entré en phase béta 2.0, et Hasin Hayder nous a envoyé un résumé des améliorations.

“
1. Prototype fait partie de Zephyr
2. Support de SQLite
3. Filtres multi-niveaux
4. Processus pré-action multiples
5. Supporte plusieurs base de données (du même ou de providers différents)
6. Possibilité de paramétrage global
7. Execution du script inclus
8. les chaines de caractères Multibyte sont supportés
9. Package d’initialisation
”

Source: http://ajaxian.com/archives/catching-users-javascript-…-logs

Récupérer les erreurs Javascript sur les log de votre serveur

Markku Uttula a admis coder en étant bourré and a décidé d’écrire un petit hack qui capture les erreurs javascripts et les envoi à ses fichiers de log sereveurs en utilisant Ajax.

Vous aimeriez en faire autant? Peut être pour améliorer vos tests utilisateurs de votre framework?

Babozor:
Effectivement, utile… pour un debuggage optimal

Depuis quelques semaines certaines personnes ont fait très justement remarqué dans certains posts que le niveau de certaines applications utilisant Ajax pouvait laisser à désirer au point de vue sécurité. Malheureusement ce phénomène n’est pas réservé à Ajax et touche beaucoup d’applications web qui sont peu ou mal sécurisés.

Nous allons donc essayer de faire le tour des différentes failles possibles et leurs réponses.

Dans la première partie nous tenterons d’expliquer les bases d’une sécurité adéquate, en reprenant la base et certains aspects fonctionnels.
Dans la deuxième partie (qui devrait arriver d’un jour à l’autre)  nous nous intéresserons plus à des cas d’écoles et à leurs solutions.

Les risques
Les risques qu’encourent une applications sont de deux types, que nous apellerons attaques belliqueuses et attaques malicieuses.
Les attaques belliqueuses sont des attaques qui tentent de prendre le contrôle ou des informations en s’attaquant directement à l’infrastructure du serveur. Ces attaques sont liés à des éventuels problèmes de sécurité de la plateforme et ne concernent en rien la programmation de l’application et nous laisserons donc nos amis les administrateurs réseaux et autres personnes de l’exploitation s’arranger avec ces attaques belliqueuses.
Les attaques malicieuses sont plus difficiles à cerner, en général elles utilisent un faille dans la programmation de l’application web pour récupérer des informations auxquelles l’utilisateur n’a pas l’accès, effectuer des créations, modifications, suppressions, etc…
Ce sont ces attaques qui sont sous la responsabilité directe du programmeur de base, qui doit s’assurrer à tout moment que les informations qu’il délivre ou les actions qu’il autorise sont bien destinées au bon utilisateur et que ces instructions ne peuvent pas être utilisés par un petit malin dans un fjord norvégien ou en plein coeur de Paris.
Quelques principes de base
Nous allons rapeller quelques principes de base, aussi bien fontionnels que techniques qui sont à suivre en toutes circonstances pour garantir un niveau minimum de sécurité à votre application web (je sais certaines recommandations paraissent idiotes, mais vous n’avez pas idée du nombre de fois où elle ne sont pas respectées).
1. ne JAMAIS mettre un mot de passe en clair dans une page (mais alors vraiment JAMAIS, vous rigolez, je le vois, mais je l’ai déjà vu… alors ne rigolez pas trop)
2. les mots de passes stockés en base doivent être hachés (ou alors cryptés, mais le mieux reste hachés)
3. les données ultra sensibles (types numéro de carte bleu, etc…) ne doivent jamais être stockés nulle part (c’est le meilleur moyen de ne jamais se les faire voler)
4. personne, pas même l’administrateur du service ne doit avoir un accès aux mot de passes et données sensibles (comme cela aucun usurpateur ne peut tomber sur ces informations…) si le client pert son mot de passe, on lui en regénère un et on lui envoi par email…
5. Si vous ne voulez pas que quelqu’un “pique” certaines informations, ne les mettez pas en ligne (je sais c’est con de dire ça, mais c’est encore la meilleure sécurité qui existe aujourd’hui)
C’est votre devoir de développeur d’avertir votre chef de projet ou votre responsable des dangers des attaques malicieuses sur votre service et donc d’imposer ces quelques règles de base simples… Si ces règles ne sont pas respectées, le reste ne reste à rien ou en tout cas pas à grand chose.
Les requêtes
Pour certains ces notions semblent couler de source, mais 90% des développeurs ne comprennent que de façon superficielle certains concepts essentiels et fondateurs du web d’aujourd’hui…
Ces notions sont très importantes, puisque c’est sur ces bases que se fonderont les attaques malicieuses et donc aussi votre technique de défense (ton kung fu très bon…)
Les échanges sur le web se basent sur le protocole HTTP.
Ce protocole est assez simple à appréhender.
Vous voulez aller jeter un oeil sur une page web, en l’occurence http://www.babozor.com/index.php
Pour faire ceci, votre navigateur va envoyer un requête au serveur qui héberge ce site web et lui demander de bien vouloir lui renvoyer la page demandée.
Cette action est donc un requêtes du client vers le serveur.
Le serveur peut répondre de divers manières, si la page est valde et que vous y avez accès, il vous renvoi le contenu de la page qui est interpréte par votre navigateur et affiché par celui ci. Si il y a un problème, le serveur renvoi un code (par exemple la fameuse 404 pour une page inconnue, etc…) qu vous renseigne sur le problème survenu.
Traditionnellement il y a 2 façons d’envoyer des requêtes vers un serveur:
- GET: vous envoyez votre requête sous la forme d’un chaine de caractère qui comprend l’url de la page et toutes les variables (par exemple http://www.babozor.com?leplusfort=babozor)
- POST: vous envoyez votre requête au serveur sous la form d’une url et d’un chaine de caractère rajouté au header de la requête qui content les variables.
Quelle différence? pour le serveur aucune ou presque, à part de rendre explicite les variables en GET dans le navigateur (le client voit les variables dans la barre d’adresse de son navigateur).

Client / Serveur
Cette notion là encore est une notion fondatrice que peu de développeur maitrisent vraiment.
Les attaques malicieuses ne viennent jamais du serveur (sinon ce sont des attaques malicieuses, et ne vous concernent plus), mais du client.
Aucune action ne peut être effectuée sur le serveur si on ne les autorise pas. Pourquoi?
Que vous utilisiez ou non un langage dynamique (j’espère, sinon ce post vous n’est d’aucune utilité), la page affichée à l’utilisateur est une page statique, générée par Apache avec l’aide de PHP… PHP ou tout autre langage web n’est qu’une sous couche du serveur web, qui aide celui ci à construire ses pages. Les pages délivrées à l’utilisateurs sont toujours statiques, il ne peut en aucun cas les modifier… c’est vous qui modifiez les pages, le client ne peut que les visualiser.
C’est un concept important à saisir.
Il est donc important de saisir la relation embivalente Client / Serveur.
Le client envoi des requêtes et reçoit des réponses, le serveur traite ces requêtes et lui renvoi des pages.
Certains contrôles basiques peuvent être effectués côté client (tel que validation d’un formulaire, par exemple), mais ces contrôles restent limités. Par exemple, on ne vérifie pas le mot de passe côté Client, puisque ça voudrait dire envoyer “en clair” le mot de passe au navigateur pour que celui ci vérifie sa validité. Un contrôle mot de passe doit toujours rester côté serveur.
Les contrôles côté client doit être limités à la comodité pour l’utilisateur…
Cette notion est d’autant plus importante à maîtriser, si vous vous lancer dans le codage d’une application Ajax, où la délimitation entre Seveur / Client devient plus floue… ce passage n’est pas nécessairement associé à une page, mais à un requête et à une réponse du serveur.

Bon je crois qu’on en a assez fait pour maintenant. Pour certains cela a du rafraichir quelques souvenirs et pour d’autres leur causer un gros mal de crâne.
Demain on s’attaque aux choses sérieuses, les attaques malicieuses et la protection contre des actions non autorisées.

Source: http://ajaxian.com/archives/phpclassesorg-chooses-iframes-over-ajax

PHPClasses.org choisit les iFrames au détriment d’Ajax?!

Quand les gens regardent pour la première fois les possibilités d’Ajax, il semble qu’ils soient immédiatement retournés et s’y lancent à pied joint. Bien sûr, d’autres plus mitigés, prennent Ajax comme un moyen d’ajouter certaines fonctionnalités à leur site web, mais ne semblent pas convaincu. Ils se retranchent donc vers des notions connus et qui marchent pour eux - la traditionnelle iFrame.

Une exmple est ce post sur le blog de PHPClasses qui parle du choix de Manuel Lemo de passer par des iFrame au lieu du XmlHttprequest pour la nouvelle version de son site, PHPClasses.org.

“
Ce plu-in Ajax que j’ai développé n’utilise par l’objet XMLJttpRequest. Il utilise à la place des iFrame cachées. Certains considèrent l’AJAX comme la seule méthode pour une interaction serveur-navigateur, grâce à l’objet XmlHttpRequest. Cette définition est fausse puisqu’on peut utiliser les iFrame pour les même besoins.
Je voudrais donc partager avec vous les raisons pour lesquelles j’ai choisi les iFrames plutôt que l’objet XMLHttpRequest.
“

Cretaines de ces raisons sont: “Compatibilité navigateurs”, “Les contraintes de sécurité des navigateurs” et “Rapidité de réponse”. Il base sa discussion sur une présentation qu’il a assisté qui disait que Ajax convenait pour de petites requêtes, mais qu’une iFrame pouvait supporter des requêtes plus larges, d’une façon plus facile et plus rapide que son homologue. Il cite aussi une autre raison pour sa décision: avec une connexion Ajax, les données ne sont disponibles qu’à la fin de la requête, alors que l’iFrames peut renvoyer des données partielles. Quelques autres arguments sont avencés, comme la possibilité de faire plusieurs actions dans la même requête et qu’il n’y a pas de méthode directe qui gère l’upload de fichier.

Babozor:
Je ne suis pas sûr que ce choix soit impartial, mais peut être pour aller à contre-courant de la tendance actuelle. Personnellement je ne vois pas l’intérêt d’un iFrame caché, alors que même pour des applications aux besoins gourmands, l’Ajax peut soutenir largement la comparaison. Il n’en reste pas moins, que la question reste ouverte…

Depuis quelques mois, à chaque fois ou presque que je postule à un job (malgré mon expérience qui semblerait plaider en ma faveur), une fois sur deux, je dois passer par la pénible épreuve du fameux questionnaire technique.
Généralement arbitraire et stupide à souhait, je me suis demandé qu’est ce qui pourrait m’éviter de subir encore les foudres de ces QCM et tests algorythmiques débiles.
Je me suis donc dit que la meilleure des choses serait de passer une certaification pour pouvoir prouver à mes futur employeurs, que je n’était pas une bille en PHP et que donc les tests se révèleraient superflus.
J’ai cherché et apparement la seule certification réellement valable en PHP, est la certification proposée par Zend.
Je me suis donc mis à potasser le bouquin de préparation à cette certification.
Certes le passage de l’examen est payant (comptez 125 dollars us), mais le potassage se révèle pour le moins payant. Il m’a permis de mettre en avant les côtés peu étudiés de certains aspects du PHP que je maitrisait moins bien et donc de me permetter d’y remédier.
D’autre part en regardant de plus près sur le site de Zend, je me suis aperçu que seuls 21 personnes en France possédaient cette fameuse certification. Oui vous avez bien entendu, seulement 21 personnes. Cela ne veut pas dire que seuls 21 personnes sont ‘balèzes’ en PHP en France, que néni, mais seulement 21 ont passé cet examen avec succès.
Je vais donc m’y essayer d’ici quelques mois. Et d’ici là je vais potasser tout ça pour l’avoir cette f**** certification.

La certification Zend
La liste des ‘certifiés Zend’ français

Beaucoup de personnes me regardent d’une oeil bizarre quand je leur dis quel est mon métier.
C’est pas évident de résumer son métier en quelques mots, donc pour ceux qui ne connaissent rien ni au PHP ni à toute l’éventuelle complexité que peut recéller (là je suis pas sûr de l’orthographe) la conception et réalisation d’un site web, je leur dis que je “fabrique” des sites web.
Beaucoup me regardent d’un oeil vide et me disent
“Ah ouais, mon petit cousin, fait ça aussi…”
Pour eux “fabriquer” un site web, c’est facile.
Ahhhh! Nan, c’est pas facile… beaucoup confondent, leur petit cousin qui fabrique son site web perso ou de fan de Lorie avec la conception et réalisation d’un site professionnel.
Le même amalgame est fait quand on dit qu’on programme en PHP, c’ets du genre “Ah ouais moi aussi je fais du PHP…”.
Mon frère est capable (ou presque) de coder en php, ce n’est pas pour autant (même si il est super balaise mon fréro… ça ne remet pas en doute son Qi ou ses capacités intellectuelles) qu’il sera capable de concevoir et réaliser un site web complexe.
C’est deux poids, deux mesures.
De même, quand quelqu’un code en PHP, il peut avoir une approche, laxiste ou professionnelle.
L’approche laxiste réside dans le fait de coder un site ou un service qui marche.
L’approche professionnelle réside dans le fait de coder un site ou un service qui soit maintenable, exportable, réutilisable, customisable par n’importe qui facilement… par implémenter des classes et des fonctions dans le code, essayer de mutualiser le développement, de raisonner sur les données et non seulement sur les pages, etc… séparer la récupération de donnée et son affichage, etc…
Tout ceci peut sembler abstrait et un peu tordu, mais c’est la différence principale entre une approche d’amateur éclairé et celle d’un professionnel.
J’essaye autant que faire se peut, d’avoir une approche professionnelle, de réfléchir avant de me mettre à coder, de mutualiser mes développements, etc… même si certaines fois cette approche se révèle impossible à mettre en oeuvre pour des questions de timing ou de délais.
Il n’empêche, que c’est profondément énervant d’entendre à tout bout de champs:
“Ah ouais tu développes des sites web, moi aussi j’ai créé mon site… tu pense que tu pourrais me trouver un boulot dans ta boîte”.
Nan je peux pas te trouver de boulot, alors arrêtes, portasse des bouquins ou la doc de php.net, forme toi, et ensuite on verra.
C’est bon j’ai fini de m’énerver… et vous c’est quoi votre expérience?