Url rewriting quelle syntaxe

Kmacleod · 24 Janvier 2003

Après avoir bidouillé pour m'en sortir, je seche

Quelle est la syntaxe que je pourrais employer pour une adresse de ce genre

articles.php?pg=site11&doc=item0849
en sachant que site11 est un fichier texte site11.txt
et que item0849 est un fichier text item0849.txt
ces deux fichier passent ensuite dans des includes

J'ai essayé :
RewriteRule ^article([0-9]+)item([0-9]+)\.html$ article.php ?pg=$1&doc=item$2 [L]
RewriteRule ^article([0-9]+)\.html$ article.php ?pg=$1&doc [L]
marche pas, mais ne plante pas

RewriteRule ^article([0-9]+)(item([0-9]+))\.html$ article.php?pg=$1&doc=$2 [L]
marche pas mais ne plante pas

Je me demande si il ne faudrait pas modifier dans mon script pour n'avoir que
articles.php?pg=11&doc=0849
avec 11.txt et 0849.txt, toujours en include

Gralon · 24 Janvier 2003

^article-(.*)-item(.*)\.html$ article.php?pg=site$1&doc=item$2 [L]
devrait fonctionner pour
article-11-item0849.html ---> article.php?pg=site11&doc=item0849

ou plus généralement :

^article_(.*)_(.*)\.html$ article.php?pg=$1&doc=$2 [L]
devrait fonctionner pour
article_site11_item0849.html ---> article.php?pg=site11&doc=item0849

hetzeld · 24 Janvier 2003

Gralon a dit:
^article-(.*)-item(.*)\.html$ article.php?pg=site$1&doc=item$2 [L]
devrait fonctionner pour
article-11-item0849.html ---> article.php?pg=site11&doc=item0849

Ne jamais faire cela ! C'est la porte ouverte aux crackers !
(.*) veut dire n'importe quoi, y compris "h**p://baddomain/badscript.php" :twisted:

Il faut être plus strict, par exemple vérifier lorsqu'on fait l'include que le fichier inclus est bien sur le même domaine, par exemple en préfixant son nom avec un chemin "en dur" du type:
include("monchemin/tranquille/".$fichier);

Il vaut mieux utiliser :

Code:

RewriteRule ^article-pg([0-9]+)-doc([0-9]+)\.html$  article.php?pg=site$1.txt&doc=doc$2.txt [L]

permet de renommer
article-pg11-doc0849.html en article.php?pg=site11.txt&doc=doc0849.txt

Dan

PS: attention aux espaces avec les copier/coller il n'y en a que 2: après le $ et avant le [L]

absoluteweb · 24 Janvier 2003

Normal que cela ne fonctionne pas [0-9] attend uniquement une valeur numérique...

Kmacleod · 24 Janvier 2003

Merci Dan,

mais pour le problème de sécurité, celà constitue une porte d'entrée, mais la porte n'est pas visible au regard de l'adresse - je veux dire par là que celui qui veut essayer d'entrer doit tatonner et esaayer plusieurs fois avant effectivement de passer (avec un script en boucle c'est surement vite fait)

Je vais plustôt essayer ta solution, je ne sais pas mais elle m'inspire mieux.

Pourquoi rajouter les .txt dans la partie de droite alors qu'ils n'y sont pas habituellement

Pour l'include avec chemin absolu, non seulement je fait un include avec ce path là, mais auparavant, je teste que le fichier existe, pour eviter les erreurs

Question subsidiaire : l'url rewritting et plus généralement le .htaccess peut il être testé en local avec serveur apache avec le bon mode positionné dans le fichier de configuration (http.confd)

absoluteweb · 24 Janvier 2003

Au fait, tu sembles avoir changé d'avis sur l'URL Rewriting, même pour ton site :?: :lol:

hetzeld · 24 Janvier 2003

Kmacleod a dit:
Merci Dan,
Pourquoi rajouter les .txt dans la partie de droite alors qu'ils n'y sont pas habituellement
...
Question subsidiaire : l'url rewritting et plus généralement le .htaccess peut il être testé en local avec serveur apache avec le bon mode positionné dans le fichier de configuration (http.confd)

Salut Kmacleod,

J'ai mis les .txt en suivant ton exemple. Cela dépend de la manière dont ton fichier exécute l'include, bien sûr. Tu peux les laisser tomber si ton programme php les rajoute de lui-même.

Tu peux tester l'URL rewriting en local. Si tu es sur Windows, il faut Apache 1.3.27 minimum parce que sinon il y a un bug "connu" de réécriture. Par exemple, avec la version 1.3.20 d'Apache installée par EasyPHP (largement utilisé) cela ne fonctionne pas correctement. J'ai mis un moment avant de trouver pourquoi. :x

Les bons paramètres pour httpd.conf sont (en local):
"AllowOverride All" (attention à la sécurité si tu n'es pas le seul à utiliser le serveur)
et "AccessFileName .htaccess" (c'est mis par défaut)
Il faut aussi t'assurer que:
LoadModule rewrite_module modules/mod_rewrite.so
AddModule mod_rewrite.c
ne soient pas commentés (ils le sont par défaut)

Si tu n'arrives pas à utiliser les mêmes règles que sur ton serveur distant, tu peux définir un autre nom que .htaccess, par exemple "AccessFileName .htaccesslocal".
C'est utile si tu dois utiliser RewriteBase en local à cause d'une install non standard.
Cela peut éviter bien des co....ries si tu synchronise les deux bécanes sans réfléchir.
Une synchro non réfléchie m'a un jour valu de faire 250000 hits en moins de 2 heures chez OVH alors que cela marchait chez moi...

Si tu coinces avec tes règles et que le problème n'est pas "d'intérêt général" , envoie moi un message.

Dan

Yvan · 24 Janvier 2003

Je confirme qu'on peut faire marcher l'URL Rewriting en local (ma config : XP Home Edition / Easy PHP 1.5). Le problème est parfois que sous windows on ne peut pas renommer un fichier en ".htaccess". La technique c'est de le faire par les commandes MS-DOS (cmd.exe sous XP/2000/NT), et de taper la ligne de commande : rename htaccess.txt .htaccess

Yvan.

hetzeld · 24 Janvier 2003

Yvan a dit:
Je confirme qu'on peut faire marcher l'URL Rewriting en local (ma config : XP Home Edition / Easy PHP 1.5). Le problème est parfois que sous windows on ne peut pas renommer un fichier en ".htaccess". La technique c'est de le faire par les commandes MS-DOS (cmd.exe sous XP/2000/NT), et de taper la ligne de commande : rename htaccess.txt .htaccess

Yvan.

Yvan,

J'imagine que tu n'as jamais essayé d'utiliser le "RewriteBase" :wink:

Dan

PS: tu devrais passer à EasyPHP 1.6, au moins tu aurais une version plus récente d'Apache et mySQL

Yvan · 24 Janvier 2003

Heu non, ça sert à quoi (je n'en ai pas trouvé trace dans ton magnifique article) ?

Yvan.

Gralon · 24 Janvier 2003

hetzeld a dit:
Gralon a dit:

^article-(.*)-item(.*)\.html$ article.php?pg=site$1&doc=item$2 [L]
devrait fonctionner pour
article-11-item0849.html ---> article.php?pg=site11&doc=item0849

Cliquez pour agrandir...

Ne jamais faire cela ! C'est la porte ouverte aux crackers !
(.*) veut dire n'importe quoi, y compris "h**p://baddomain/badscript.php" :twisted:

Il faut être plus strict, par exemple vérifier lorsqu'on fait l'include que le fichier inclus est bien sur le même domaine, par exemple en préfixant son nom avec un chemin "en dur" du type:
include("monchemin/tranquille/".$fichier);

ben ça paraît évident qu'il faut vérifier que l'include est bien sur ton serveur (et dans ton répertoire).
c'est sur que si il fait un simple include du paramètre dans son url .... arghhhhhhh

désolé j'ai pas pensé que certain oublierai ça ...

c'est pourtant un pb connu

Kmacleod · 24 Janvier 2003

Comment se voit un UR actif en local

Les adresses des liens internes sont modifiés et sont en html ?
L'URL est devenue html
L'url en forme html fonctionne et c'est la page en php qui s'ouvre

Question triviales ....

hetzeld · 24 Janvier 2003

Yvan a dit:
Heu non, ça sert à quoi (je n'en ai pas trouvé trace dans ton magnifique article) ?
Yvan.

Merci pour l'éloge :wink:

En fait, cela pourrait faire partie de la suite de l'article que je suis occupé à concocter, mais j'hésite franchement parce que cela risque de semer la confusion dans les esprits.:wink: ...

Essayons d'expliquer par l'exemple, soit la règle (facile):

Code:

RewriteRule   ^ancien\.html$  nouveau.html

définie dans le fichier /abc/def/.htaccess (on parle ici de répertoire physique sur le serveur et non d'URL)

Si le serveur a une directive d'alias définie comme:

Code:

Alias /xyz /abc/def

Un même fichier physique peut être accédé sous /xyz/nouveau.html ou /abc/def/nouveau.html et donc, dans notre exemple, la réécriture de:
/xyz/ancien.html se fera en /xyz/nouveau.html
et celle de
/abc/def/ancien.html se fera en /abc/def/nouveau.html

Avec la directive "RewriteBase /xyz" et une requête pour /xyz/ancien.html,
les étapes de la réécriture sont les suivantes:

Code:

/xyz/ancien.html     -> /abc/def/ancien.html  (dû à l'Alias)
/abc/def/ancien.html -> /abc/def/nouveau.html  (dû à la RewriteRule)
/abc/def/nouveau.html -> /xyz/nouveau.html      (dû à la RewriteBase)
/xyz/newstuff.html     -> /abc/def/newstuff.html  (dû à l'Alias)

Donc un appel de /xyz/ancien.html donnera bien le bon fichier (et le bon répertoire serveur) /abc/def/nouveau.html

C'est tordu, mais c'est comme cela qu'Apache fonctionne en interne :wink:

Tu comprends pourquoi je n'ai pas voulu encombrer l'article avec un truc don peu de nous se servent. C'est principalement utile pour les admin système chez les hébergeurs, pas pour les utilisateurs comme nous.
Si tu avais une bécane avec plusieurs domaines et des Alias définis, tu en aurais besoin :wink:

Dan

Yvan · 24 Janvier 2003

Et bien merci de ta réponse plus qu'enrichissante. J'y penserais si un jour j'ai mon propre serveur !

Sinon je ne peux pas mettre EasyPHP 1.6, car il plante sous XP, donc j'utilise le 1.5 seulement pour l'exécutable, après avoir installé le 1.6. J'ai donc bien Apache 1.3.4, PHP 4.2.0 et MySQL 1.23.39. De toute manière c'est en local, et ça diffère un peu du serveur sur lequel je suis hébergé.

Yvan.

hetzeld · 24 Janvier 2003

Kmacleod a dit:
Comment se voit un UR actif en local
Les adresses des liens internes sont modifiés et sont en html ?
L'URL est devenue html
L'url en forme html fonctionne et c'est la page en php qui s'ouvre
Question triviales ....

Il n'y a pas de questions idiotes, il n'y a que les réponses qui le sont :lol:

Idéalement, tu devrais modifier tous tes liens internes pour être sous la forme nouvelle (de type "fichier.html"), cela permettrait aux moteurs de les suivre sans état d'âme...
Les anciennes URL référencées sur les moteurs seront toujours opérationelles donc avec du pot tu doubles ta présence sur ces moteurs, au moins pour un certain temps, et pour les url qui étaient indexée dans la forme antérieure (du genre 2 paramètres ou moins) :wink:

Quel que soit le langage de script (PHP/ASP/...) le navigateur ne reçoit jamais que du pur HTML (hors sites de type flash...) vu que le script génère du HTML.
Il est donc impossible de déterminer s'il y a eu réécriture, voire de déterminer le langage de script sous-jacent.

Un avantage pour ceux qui changent le langage de script pour passer, par exemple d'ASP vers PHP. Les liens visibles restent les mêmes.

A+

Dan

hetzeld · 24 Janvier 2003

Yvan a dit:
Sinon je ne peux pas mettre EasyPHP 1.6, car il plante sous XP, .

EasyPHP 1.5 posait problème sous XP mais 1.6 fonctionne au poil !
J'en ai 2 qui tournent chez moi. (Apache patché à 1.3.27 et mySQL 4.3 mais ils fonctionnaient très bien avec les versions d'origine - sauf le RewriteBase :wink: )
L'un tourne comme service windows et l'autre en CGI comme il accède des disques réseau...
Tu peux faire la mise à jour sans problème aucun, c'est sûr !

Dan

Yvan · 24 Janvier 2003

Le fait est que je ne les fais pas tourner comme services volontairement, pour ne pas qu'ils tournent alors que je ne m'en sers pas très souvent. Et c'est donc là que ça pose problème. Sinon c'est vrai, en tant que services y'avait pas de problème. Donc 1.5 > lancé comme programme simple et 1.6 > lancé comme service, dans les 2 cas ça tourne au poil :wink:

Quant au RewriteBase, je n'en vois pas l'utilité pour mon site unique. Donc tout va bien au final !

Yvan.

Kmacleod · 24 Janvier 2003

Pour revenir au post d'origine :wink:

Sur localhost, l'UR repond au travers du htaccess, mais ne fonctionne pas.
J'ai modifié quelques liens pour les avoir de la forme fichier.html, mais rien n'y fait, le resultat est "page non trouvée". donc la fache 404 personalisée s'affiche (au moins ca ca marche)

Peut être qu'en ligne le resultat sera different, j'y crois pas trop ! :evil:

hetzeld · 24 Janvier 2003

Salut,

Tu peux mettre le "rewrite log" en route, au moins tu verrais ce qui cloche.
Il te faut 2 déclarations dans le fichier httpd.conf:

RewriteLog logs/fichier.log (il faut que le répertoire logs existe sous ServerRoot)
RewriteLogLevel 3 (valeur de 0 à 9 -> 0=off , 9=full ...énorme!)

Dan

Kmacleod · 25 Janvier 2003

Ok pour l'UR qui fonctionne désormais en ligne, mais pas en local (?)

Merci et coup de chapeau à ceux qui ont aidé

hetzeld · 25 Janvier 2003

Kmacleod a dit:
Ok pour l'UR qui fonctionne désormais en ligne, mais pas en local (?)

Tu as quelle version d'Apache ?? Avec une version antérieure à 1.3.26 (ou 1.3.27 pour être sûr), tu verrais dans les logs qu'il réécrit mal certaines URL locales alors que ce bug n'existe pas sur Unix/Linux. Lorsque je cherchais pour moi, j'ai trouvé un article sur les forums Apache où ce bug était parfaitement décrit!
Tu te retrouve avec une adresse de fichier réécrite du genre /rep1/rep2/c:\de_la_daube\ici_aussi qui bien sûr ne peut pas te donner un fichier... :cry:

Dan

Kmacleod · 25 Janvier 2003

Pour apache j'ai la V 1.6 testée en local sous Windows 2000/NT avec droit admin
Je vais l'essayer sous Win 98, et éventuellement chercher une version antérieure.
Mais la 1.6 passe peut-être bien sous Win98
C'est un peu important en local pour la mise au point.
Si on peut faire le point pour les versions d'Apache ou mieux easyphp pour savoir laquelle fonctionne pour l'UR en localhost et sous quel OS (voir navigateur)

hetzeld · 25 Janvier 2003

Kmacleod a dit:
Pour apache j'ai la V 1.6 testée en local sous Windows 2000/NT avec droit admin
Je vais l'essayer sous Win 98, et éventuellement chercher une version antérieure.
Mais la 1.6 passe peut-être bien sous Win98
C'est un peu important en local pour la mise au point.
Si on peut faire le point pour les versions d'Apache ou mieux easyphp pour savoir laquelle fonctionne pour l'UR en localhost et sous quel OS (voir navigateur)

Il n'y a pas de version Apache 1.6.... :roll:
La dernière version 1.x est la 1.3.27 suivie par les versions 2.x

J'imagine que tu parles de EasyPHP 1.6 ... dans ce cas la version Apache (1.3.24) est buggée pour le mod_rewrite,

Ce bug est corrigé à partir de la 1.3.26
Le mieux étant d'installer soi-même Apache, PHP et mySQL comme cela permet un meilleur contrôle des versions.

Dan

Kmacleod · 25 Janvier 2003

Exact Dan, mes doigts sont glissés sur le clavier (hum-hum)
Si tu veux que'lon installe soit même PHP, MySQL, et apache; pas de problème, celà me semble compliqué , le .httaccess est simple, l'UR aussi (quand on a compris), alors demande à Olivier d'ouvir un forum.

Le plus simple serait à partir de l'installation d'Easyphp, de pouvoir corriger ce bug, en re-installant l'élément défaillant (apache V1R3M6).

Je suppose que dans les version inférieures à la 1.3.24 sont soit aussi buggées, soit ne font pas de UR.

Sinon comment contourner le problème ?

hetzeld · 25 Janvier 2003

Kmacleod,

Moi j'ai écrasé la version Apache installée par EasyPHP par une 1.3.27 sans problème.
Je crois savoir qu'ils en parlent sur les forum EasyPHP.
J'essaye toujours d'avoir la même version que mon hébergeur (OVH), aussi bien pour Apache que pour php. Au moins je peux développer tranquille !

Dan

ps: email perso envoyé :wink: