Guide sur les nsCOMPtr :

http://www.mozilla.org/projects/xpcom/nsCOMPtr.html

Guide pour utiliser les strings :

http://developer.mozilla.org/en/docs/XPCOM:Strings

Guide pour utiliser les hashtables :

http://developer.mozilla.org/en/docs/XPCOM:Hashtables

Guide pour utiliser les tableaux :

http://www.mozilla.org/projects/xpcom/array-guide.html

Sinon

http://www.mozilla.org/projects/xpcom/

http://developer.mozilla.org/en/docs/XPCOM

Et toute la doc en général pour ceux qui veulent travailler sur les sources de Mozilla :

http://www.mozilla.org/docs/

Laurent Jouanneau

http://ljouanneau.com

Technologies XUL/Mozilla

http://www.xulfr.org

Pour les standards du web

http://openweb.eu.org

http://www.mozilla.org/developer/

http://developer.mozilla.org/en/docs/Mozilla_Source_Code_Via_CVS#Getting_Started

Utiliser * html {}

IE 7 et inférieurs

Utiliser *+html, * html {}

IE 7 seulement

Utiliser *+html {}

IE 7 et navigateurs modernes seulement

Utiliser html>body {}

Navigateurs modernes seulement (IE 7 non inclus)

Utiliser html>/**/body {}

http://blog.pixarea.com/index.php/2006/06/13/39-css-un-hack-simple-pour-ie7

http://www.webdevout.net/articles/css_hacks.php#p2006.4.28.22.56:12

http://www.code-sucks.com/css%20layouts/faux-css-layouts/

http://www.alistapart.com/articles/holygrail

http://www.stopdesign.com/articles/throwing_tables/

http://www.csszengarden.com/

http://www.deliciouscss.com/

http://www.alistapart.com/articles/outsidethegrid

http://www.pathf.com/blogs/2006/07/multi_column_la_1/

/%category%/%postname%/

Le premier fichier à hacker est le suivant:

/wp-includes/template-loader.php

Il faut ajouter au début du fichier le code suivant:

$category_test = get_category_by_slug($wp_query->query_vars['name']);
if(!empty($category_test))
{
$wp_query->query_vars['subcategory_name'] = $wp_query->query_vars['category_name'];
$wp_query->query_vars['category_name'] = $wp_query->query_vars['name'];
$wp_query->query_vars['cat'] = $category_test->cat_ID;
$wp_query->query_vars['name'] = '';
$wp_query->is_subcategory = true;
$wp_query->is_archive = true;
$wp_query->is_category = true;
$wp_query->is_page = false;
$wp_query->is_404 = false;
}

Ce code permet à l’engin de template de bien appeler notre script de catégorie lorsqu’il voit une sous-categorie.

Ensuite, il faut s’assurer que la page des catégorie sais faire la différence entre les deux, et qu’elle n’affiche pas les sous-éléments si c’est seulement la catégorie, et qu’elle recalcule sa liste si c’est une catégorie.

Par exemple, ce code s’assure que seulement les éléments de la catégorie demandées sont affichés.

$category_post = get_the_category();
$category_post = $category_post[0];
if($category_post->category_parent == $category_page->category_parent)

En ajoutant celle ligne on obtient un recalcul de la liste des posts, très utile dans le cas d’une sous-catégorie.

cat_ID.''); $wp_query->post_count = count($posts);?>

Le code total devient:

cat_ID.''); $wp_query->post_count = count($posts);?>

$category_post = get_the_category();
$category_post = $category_post[0];
if($category_post->category_parent == $category_page->category_parent)
{?>

Enfin, il peut être intéressant d’afficher des liens vers les sous-catégories dans la page de la catégorie. Voici comment.

category_parent != 0) $category_parent = get_category($category_parent->category_parent); $sous_categories = get_categories('child_of=' . $category_parent->cat_ID);  foreach($sous_categories as $sous_categorie) { ?> name;?>

msgfmt fichier.po -o fichier.mo

Ensuite, une fois le fichier obtenu, il faut aller le placer avec un logiciel FTP, SFTP, ou même SCP dans le répertoire web de notre site web.  Voici la localisation exacte.

/wp-content/languages/fr_FR.po

/wp-content/languages/fr_FR.mo

Enfin, la dernière étape consiste à informer Wordpress du fichier de language qu’il doit utiliser pour son interface utilisateur, on édite le fichier de configuration /wp-config.php

define ('WPLANG', '');

Il suffit de spécifier fr_FR comme ceci:

define ('WPLANG', 'fr_FR');

Grossièrement, ce qui se produit est soit (1) l’insertion de commandes pour la base de données ou encore (2) la transformation des paramètres de manière à faire appliquer des commandes sur des données non-autorisées.

L’insertion arbitraire de commandes

Ce type d’injection SQL implique qu’il existe des caractères spéciaux capables d’interrompre une commande SQL existante et d’en débuter une nouvelle dictée par l’attaquant. Cette attaque est de loin la pls dangereuse car elle s’exécutera avec les privilèges de l’usager de la base de données et non avec les privilèges de l’usager du site.

La plupart des applications web ne déclinent pas leurs base d’usagers en différentes connections à la base avec différents privilèges. NON. C’est l’application qui gèrent les droits des utilisateurs et l’application se connecte ensuite à la base de données avec un super-utilisateurs qui a tous les droits, et gare à la requête qui serait vicieusement et secrètement transformée par un attaquant.

Le type de caractère spécial capable de provoquer un arrêt de la requête SQL est le ‘;’. Heureusement, la plupart des bases sont prémunies contre cela puisqu’elles n’autorisent qu’une seule commande à la fois et c’est la première qui prévaut. Enfin, certaines applications exécutent des prétraitement sur les variables afin de les filtrer de tout caractères spéciaux ou encore afin de les encoder.

Ce type d’attaque devient de plus en plus difficile à réaliser mais quelques perches subsistent en la nature de transformations mal aiguillées par l’application, qui pourrait par exemple faire l’erreur de laisser passer la requête injectée plutôt que la requête initiale. À cet effet, les requêtes préparées à l’avance (prepared statement) apportent un niveau de sécurité supplémentaire en plus de l’optimisation apportée. Celles-ci, couplées à un engin de traitement automatique des variables injectées dans les requêtes permet d’apporter une sécurisation indépendantes des opérations de programmation opérées lors de la réception des variables.

Cependant, une grande communauté de programmeurs préfèrent opérer la filtration dès la réception des variables afin d’éviter les autres inconvénients possibles de l’injection de données.

Un bon programme de test de l’application devrait donc contenir non-seulement des injections aléatoires de données mais aussi des injections systématiques des caractères dangereux pour en vérifier l’effet réel.

Le détournement de requête par transformation des paramètres

Imaginons des données privilégiées qui sont mélangées à des données publiques dans la base de données ou encore les données personnelles de chacun qui sont contenues dans la même table.

Comme dans un appel de page web dynamique, dans la base de données il ne suffit que d’un paramètre pour modifier l’essence d’une requête. Par exemple:

• On désire obtenir toutes les information concernant Louise. Mais que se passe-t-il si on envoie le numéro de Jean même si on est authentifiée en tant que Louise ?
• On désire faire afficher une sélection de données selon des paramètres. Mais que se passe-t-il si on envoie le symbole de sélection universelle du SQL qui n’est pas l’étoile ‘*’ mais le pourcentage ‘%’
• On désire effacer une de nos fiches d’informations, mais que se passe-t-il si on modifie le formulaire et que l’on inscrit le paramètre universel à la place du numéro d’identification de notre fiche d’information ? Effacera-t-on toutes les fiches ?

La réponse à ces questions dépend de l’action coordonnées de l’architecture, de la programmation et de la formulation des requêtes SQL. Une vision d’ensemble est nécessaire et c’est pourquoi la construction des applications web doit être coordonnées et dirigées par un spécialiste du métier. Des connaissances en gestion sont bien insuffisantes car la construction d’applications web n’est pas symétrique à la construction de maisons.

Voici quelques trucs qui permettent dans certaines situations d’éviter les détournements de requêtes

• Afin de rendre impossible la généralisation d’une opération d’effacement ou de mise à jour, il est pertinent dans le SQL d’utiliser la condition = plutôt que la condition LIKE.
• Il faut réserver la condition LIKE à des recherches s’opérant dans des données déjà toutes restreintes publiques
• Afin d’éviter le détournement d’une opération de sélection, mise à jour ou effacement de données individuelles, il faut que le compte restreint génère les paramètres de conditions à partir de l’authentification revalidée.
• L’empêchement de la généralisation des opérations de recherches publiques paramétrées paraît ici moins critique en regard de la protection de l’information. Cependant, pour qui est intéressé a en limiter l’usage, il suffit d’encapsuler le caractère spécial % afin de le transformer en donnée normale (par une ‘escape’). Comme les utilisateurs désireux d’utiliser le wildcard prendront sans hésiter le symbole *, il suffit de travailler sur celui afin de le rendre disponible en complément des données existantes et d’empêcher son utilisation seule.

Dans un prochain article, je ferai un essai de procédure systématique et de tableau résumé afin d’obtenir les résultats escomptés sans limiter indûment le pouvoir de l’utilisateur.

Voici un lien complémentaire en attendant ce tableau, qui résume les attaques possibles sous forme d’une “cheat sheet”

WordPress illustre bien cette double action qui doit être menée afin de faire fonctionner la réécriture des URL.

D’une part, les url générée par le CMS sont générées selon le patron préféré tel que spécifié dans la page de configuration.

Panneau d’administration

Premièrement, l’administrateur sélectionne la section nommée ‘Permalinks’

Génération des hyperliens par l’application web

Ensuite, il choisit une des formes d’URL pré-fabriquée ou en compose une lui-même en utilisant la syntaxe permettant de spécifier la position pour la date, le titre, la catégorie, l’identifiant ou encore l’auteur du message. C’est donc de cette façon qu’on conçoit l’hiérarchie apparente du site.

La liste des variables disponible pour la création de la syntaxe sémantique est disponible sur le site officiel :

http://codex.wordpress.org/Using_Permalinks#Choosing_your_permalink_structure

Réécriture des URL par le serveur web Apache

Cette indication de syntaxe permet à l’engin PHP de générer les hyperlien correspondant au rewrite mais cependant, ce n’est pas la partie qui effectue la réécriture proprement dite afin de fournir à l’engin PHP les pages paramétrisée qu’il doit travailler à partir pourtant de requête vers des pages statiques HTML.

Ces indications sont faites avec le fichier .htaccess qui peut être généré automatiquement par WordPress si le répertoire et/ou le fichiers sont accessibles en écriture.

Ensuite, l’engin réécrit, s’il en a les droits, le fichier .htaccess afin de signifier cette nouvelle configuration des URL

# BEGIN WordPress

RewriteEngine On

RewriteBase /portail-regional/

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /portail-regional/index.php

# END WordPress

Ici, la réécriture spécifie qu’elle ne doit s’accomplir que SI et seulement SI le fichier ou le répertoire demandés n’existent pas physiquement dans l’hébergement.

L’écriture des règles au niveau des fichiers locaux .htaccess ne nécessite pas le redémarrage d’Apache comme les règles indiquées dans le fichier de configuration central.

Cependant, la surcharge doit être permise par la configuration centrale et conséquemment, l’autorisation de fichiers .htaccess ralentissent le service des pages puisque le serveur doit à chaque fois vérifier la configuration locale !

Nadine St-Amand

Formatrice et designer de logiciels

La réécriture des URL n’est malheureusement pas une opération atomique.

Si celle-ci est dictée à Apache au moyen de l’un de ses fichiers de configuration, les liens émanant des autres pages vers un lien modifié ne sont pas automatiquement réécris.

Voici donc les trois étapes nécessaires à la réécriture d’url dynamiques en url sémantiques :

• Le serveur web est configuré pour supporter la réécriture d’url par l’ajout et l’activation du module mod_rewrite

• Le serveur web est informé des réécritures qui auront cours pour chaque site web

• Le code du site web doit refléter la réécriture en utilisant les nouvelles versions d’url dans les balises d’hyperlien

Configuration serveur : ajout et activation de mod_rewrite

• Installation du module

Premièrement on vérifie que le module mod_rewrite est bien installé. De nos jours, ce module est souvent installé par défaut. Il suffit de vérifier qu’il est bien installé sur le serveur linux et chargé par le serveur web.

Premièrement, on peut vérifier la présence physique du module sur le serveur Linux :

> ls /usr/lib/apache2/modules

mod_rewrite.so

Ensuite, on s’assure que Apache charge ce module lors de son exécution

> ls /etc/apache2/apache2.conf

Include /etc/apache2/mods-enabled/*.load

> cat /etc/apache2/mods-available/rewrite.load

LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so

> ls -l /etc/apache2/mods-enabled/rewrite.load

rewrite.load -> /etc/apache2/mods-available/rewrite.load

• Activation du module

Pour activer ou désactiver le rewrite pour un site particulier il faut utiliser l’instruction RewriteEngine On/Off

> cat /etc/apache2/sites-available/ www_mon-portail-touristique_com

RewriteEngine On

Bien sur, la configuration du site prend effet seulement si elle connectée par la liste des sites actif

> ls -l /etc/apache2/sites-enabled/www_mon-portail-touristique_com

www_mon-portail-touristique_com

->/etc/apache2/sites-available/www_mon-portail-touristique_com

Note: dans l’ancienne version d’Apache, il était une pratique courante de ne pas utiliser les includes et de lister toutes les directives dans httpd.conf qui était le seul fichier de configurations plutot que d’utiliser les fichiers de sites-available/ et de mods-available/

Règles de réécritures édictées pour chaque site

• Fichiers de réécriture : le fichier de configuration principal ou le fichier local

Il est possible d’édicter des règles de mod_rewrite directement dans le fichier de configuration du site, soit dans le répertoire de configuration de Apache, là ou il était indiqué que nous activions à On le RewriteEngine.

Il est aussi possible d’édicter les règles directement dans les répertoires du site web avec les fichiers locaux de configuraiton .htaccess

• Langage de la réécriture : les expressions régulières

On veut transformer une url dynamique :

http://www.mon-portail-touristique.com

/portailregional.jsp?region=4&nom=Quebec

en url sémantique :

http://www.mon-portail-touristique.com/portail-regional/Quebec/

RewriteEngine On

RewriteRule ^portail-regional/([0-9]+)/ ([^_]+) \.html$ portailregional.jsp?region=$1&nom=$2

Après avoir effectué les ajustements à la configuration, il faut redémarrer Apache :

sudo apache2ctl graceful

• Modes ou modificateurs de réécriture

Il existe différents modes d’applications des règles de réécriture.

Par exemple, le drapeau [R] placé après une règle de réécriture provoque le rechargement de l’url par le navigateur.

Synchronisation des hyperliens

Si le site est dynamique, comme le sont les url paramétrisées, il faudra affecter les url générées par l’application web.

La manière la plus élégante de procéder est de travailler systématiquement. Pour chaque règle énoncée dans le fichier de configuration de Apache, il faut créer une règle de transformation dans le code dynamique de l’application web.

Par exemple, dans le site de portail touristique, il faudrait que toutes les listes de liens vers les portails régionaux voient leurs url des hyperliens ajustées à la nouvelle nomenclature.

Ainsi, avant nous faisions une boucle qui ressemblait à ceci :

&nom=<%=nom %>”><=%nom %>

Maintenant, il faut ajuster ce code et écrire :

/<=%nom %>.html”><=%nom %>

Architecture favorable de l’application web

C’est pourquoi il est important d’architecturer l’application en centralisant autant que possible l’écriture des liens vers les autres pages: donc les menus, les fils d’ariane et les listes de sous-pages sont centralisés.

L’architecture sera d’autant plus cohésive si les fichiers .htaccess sont hiérarchisés de la même manière que les générateurs d’url.

]]> http://journal-web-formation.accentnet.org/referencement/reecriture-des-url-dynamiques-en-url-semantiques-partie-2/feed/ 0 http://journal-web-formation.accentnet.org/css/jutilise-deja-les-css-oui-mais-apres/ http://journal-web-formation.accentnet.org/css/jutilise-deja-les-css-oui-mais-apres/#comments Sun, 04 Apr 2010 15:19:55 +0000 Nadine St-Amand pour Les formations Accent Net http://journal-web-formation.accentnet.org/?p=14 Il y a quelques temps, je proposais à mon patron de l’aider dans la conversion de ses sites actuellement en tableau vers des versions parfaitement propres basées sur le XHTML/CSS. Merci, me répond-il avec un petit sourire, mais nous avons déjà un programmeur qui connait les CSS. J’étais incapable de lui expliquer en mots simples qu’il y avait une différence majeure entre un site qui contient des CSS et un site basé sur celles-ci. Je bredouillai quelque chose de diplomatique et le sujet était clos.

Cycle commercial — les uns ont avertis de l’importance des CSS dans le développement de sites modernes, optimisés ‘SEO’ pour les engins de recherches — et les autres ont répondus à cet avertissement en ajoutant les CSS dans leurs sites. Le plaster est posé sur le bobo et tout est réglé.

Est-ce suffisant ? De la même manière, ajouter des aliments régime par dessus une alimentation trop riche en graisse vous fera-t-il maigrir ? La réponse est non.

L’ajout de CSS à un site web qui n’est pas sémantique n’apportera pas la flexibilité et l’optimisation que l’on associe à cette technologie. Il est difficile d’expliquer cette notion sans entrer dans les détails techniques de programmeurs.

Disons seulement que les CSS ont permis la factorisation des détails de présentation dans un lieu commun. Ils ont aussi évité la redondances de ces indications de présentation dans diverses page. Ceci révolutionna la manière de disposer les pages web, qui était jusqu’alors basée sur les tableaux, les objets étant positionné comme on déposerait divers article sur un étagère de verre pour les positionner dans l’espace.

Cette fragmentation historique du contenu, par les cellules de notre étagère-tableau, rend les pages web illisible à leur état pur, lorsq’elle ne sont pas rendues visuellement par un navigateur tel que mozilla ou internet explorer. Les aveugles, les visiteurs en mode texte et les moteurs d’indexation ne voient pas le contenu tel qu’il est dans la page visuelle.

C’est pourquoi une nouvelle méthode de conception des pages web a été inventée. On crée un fichier sémantique, sous une forme similaire au XML, avec seulement de l’informations bien structurée et étiquettée avec les balises. C’est avec la couche CSS que les éléments sont positionnés dans l’espace, colorés, et a besoin remplacé par des images décoratives. C’est toute cette technique qui est sous-entendue lorsqu’on parle du bienfait des CSS ou encore des pages web sémantiques ou même de la SEO. Cette technique est enseignée à l’école dans le cours des Ateliers pratiques de CSS

C’est pourquoi le fait d’ajouter un peu de CSS tout en continuant de découper en petits carrés la page ne sert pas les intérêts de la page. Cette utilisation incomplète ne permet pas d’optimiser les pages d’une manière significative.

Exemple d’une URL dynamique

Ces pages dynamiques sont celles publiant sur le web les données issues de la base de données, par exemple : la page d’un produit dans un commerce électronique, la page d’un article dans un journal, etc.

Ces pages sont très mal indexées par les moteurs de recherche qui s’intéressent surtout à la sémantique de nos pages. En effet, ceux-ci considèrent les informations suivantes par ordre d’importance :

1. Le nom du domaine
2. Le nom de la page et de son hiérarchie
3. Le titre de la page (balises )
4. Le contenu

Ces informations permettent au moteur d’indexation de conserver notre page web dans la bonne catégorie de son index et parfois même de tisser des liens sémantiques entre ces contenus et ceux d’autres sites.

Comment un moteur d’indexation, tel que Google, peut-il voir la différence fondamentale entre notre région numéro 4 et notre région numéro 5 s’il n’y a pas d’autre d’informations les décrivant. D’autre part, comment pourrait-il associer cette donnée avec d’autres informations de sa base si les mots-clés décrivant la région manquent !

C’est pourquoi des informations sémantiques plus pertinentes devraient être associées à l’adresse web. Par exemple, il est préférable de publier le mot-clé principal de la région dans l’URL, même si ce mot-clé n’est pas utilisé dans la requête (dans le script de la région c’est l’identifiant numérique qui est utilisé).

Exemple d’une URL dynamique et sémantique

Ainsi, lorsque les ‘crawlers’ iront visiter notre site, ils verront distinctement la différence entre la région 4 et la région 5 et pourront identifier ce contenu avec des mots-clés.

Cependant, l’algorithme de l’engin d’indexation considèrera sans aucun doute que cette information est de second ordre si elle est placée dans un paramètre. Elle ne vaudra pas plus qu’un autre paramètre tel la langue ou le numéro de session ! Un autre facteur défavorisant l’indexation des pages paramétrées est leur nombre impressionnant et leur pertinence toute relative sur le web d’aujourd’hui. Enfin, considérons également le retard dans le développement des moteurs de recherche qui n’aide pas leur cause : celui par rapport à la capacité de gestion de ces url un peu spéciales.

Quoi qu’il en soit, c’est une vérité communément admise de nos jours qu’il vaut mieux avoir une url dans laquelle la sémantique n’est pas distribuée dans les paramètres, mais dans laquelle plutôt, la sémantique serait concentré dans le chemin de la page et le nom de la page. On tente le plus possible de présenter une adresse de page qui serait sémantique en elle-même : les mots-clés font partie du nom de la page et de ses répertoires. Voici quelques exemples ou les mots-clés sont mis en avant et les identifiants numériques sont filtrés.

Exemple d’une URL sémantique (d’apparence non-dynamique)

Exemple d’une URL sémantique (d’apparence non-dynamique)

Comment s’opère cette magie : soit présenter plusieurs noms de pages statiques par un système dynamique opérant un seul script, i.e. une seule page qui les génèrent toutes ?

C’est la réécriture d’URL, aussi connue par les expressions anglophones ‘url rewriting’ ou ‘mod rewrite’.

Dans le prochain article, nous apprendrons comment réaliser cette magie à l’aide du module mod_rewrite de Apache.

Nadine St-Amand

Formatrice et designer J2EE