Discussion :

[CUCARACHA]

Salut,

Je suis en train de bosser sur l'url rewriting sous ASP.net 3.5

Je précise que c'est du rewriting à la mano dans le globals.asax et non par HttpModule.

En fait, j'aimerais que l'adresse invoquée au départ soit celle ci qui est utilisée dans l'attribut action du form de la page et non l'adresse de la page sur laquelle la requête a été redirigée.

J'ai essaye de trafiquer render et prerender sans succès.

Quelqu'un connaîtrait-il une technique efficace ?

D'avance merci

Laurent

[nico-pyright(c)]

tu peux regarder dans mon tutoriel : http://nico-pyright.developpez.com/t...ing/#Lpostback

[nico_4802]

Bonjour,

J'ai suivi votre tutoriel sur l'implémentation de l'url rewriting, et cela fonctionne parfaitement. J'ai cependant une petite question à vous poser :

j'utilise un fichier .browser pour pallier au problème des postbacks :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<browsers>
  <browser refID="Default">
    <controlAdapters>
      <adapter controlType="System.Web.UI.HtmlControls.HtmlForm" adapterType="CMS.PAGES.URLREWRITING.FormAdapter" />
    </controlAdapters>
  </browser>
</browsers>

en local, sous IIS 7, cela fonctionne parfaitement.
Néanmoins, lorsque je place mon site sur le serveur distant en production (IIS 6, je pense) , ma classe "FormAdapter" n'est jamais exécutée, mais impossible de savoir à quel niveau se trouve le problème...

auriez-vous une petite idée, par hasard ?
Je vous remercie de votre aide.

[CUCARACHA]

Salut,

L'URL Rewriting n'est pas une fonctionnalité native de IIS 6. A l'époque de cette version il fallait utiliser un module externe comme Intelligencia URL Rewriter (tu pourras trouver des infos à ce sujet ici : http://forums.asp.net/t/1518828.aspx)

Pour ma part, j'ai développé mon propre module qui fonctionne aussi bien sous IIS 6 que sous les versions ultérieures car c'est assez facile à faire dans le global.asax à l'aide de l'évennement BeginRequest. Du coup je n'ai jamais mis en oeuvre les fonctionnalités natives IIS 7 et +.

Intelligencia URL Rewriter nécéssite un minimum de connaissance en expressions régulières voir : http://lgmorand.developpez.com/dotnet/regex/

Le conseil que je te donnerais serait de ne jamais développer sur une version IIS Plus récente que ton environnement d'execution (à la limite, le contraire peut être acceptable).

Bonne continuation

Laurent

[CUCARACHA]

En ce qui concerne l'adapter ça fonctionne, je l'ai déja mis en oeuvre dans IIS 6.

++

Laurent

[nico_4802]

merci pour la réponse,

Donc la question serait alors maintenant de savoir ce qui fait que mon fichier .browser ne soit plus interprété dans le nouvel environnement de production...

[CUCARACHA]

Il faut que tu verifies que le suffixe .browser soit bien inclu dans la liste des mappings de ton site Internet.
Je n'ai plus de serveur IIS 6 a dispo, je ne peux donc pas te guider mais de mémoire ça doit être dans la configuration de l'application.

[nico_4802]

Je viens de faire une petite découverte qui m'a surprise, peut-être me direz-vous que c'est logique, mais moi ca m'a étonné :

lorsqu'on met en place un paiement sécurisé via Ogone, on doit mentionner l'url de la page à partir de laquelle on appelle Ogone... eh bien je me suis rendu compte que l'url que OGONE recevait n'était pas celle "réécrite" mais l'url "de base" (donc celle qui contient habituellement les paramètres,... et qui est sensée justement être masquée par le processus d'url rewriting)...

[CUCARACHA]

C'est parcequ'il faut spécifier l'URL déjà rewrité au web service du système de paiement.

En fait (normalement), on poste la requête en spécifiant dans un champ l'adresse à laquelle doit être renvoyée la réponse et c'est bien de l'adresse rewritée qu'il faut mettre puisque seules ces adresses pointent sur des pages. Si on passe une adresse non rewritée ça peut ne pas fonctionner.

C'est pourquoi, dans mon cas, j'utilise un suffixe different pour les pages ASPX rewritées et celles qui ne le sont pas. Par exemple, je ne rewrite que les adresses .html. C'est avec le gestionnaire de mapping d'IIS qu'on associe le suffixe au framework.

C'est clair ?

[nico_4802]

euh, en fait on s'est mal compris...

de fait, on doit passer à Ogone l'url de la page qu'il doit appeler, une fois la transaction effectuée, afin qu'Ogone retourne à notre site le résultat de la transaction.... et ca c'est bien l'url rewritée, on est bien d'accord !

Mais dans les paramèetres de notre compte Ogone, on doit aussi définir l'url de la page qui va appeler la page d'Ogone... il s'agit généralement de la dernière étape de finalisation d'une commande, celle ou on valide la commande ; c'est ensuite cette page qui appellera Ogone pour finaliser la transaction. Ogone demande donc qu'on lui fournisse l'url de cette page d'un point de vue sécurité, afin qu'il puisse vérifier que la transaction vient bien de notre site et non d'un autre ! Et je parle bien de cette page-là... imaginons l'url suivante :

"www.monSite.com/page.aspx?type=commande&etape=derniereEtape", qu'on a rewrité en "www.monSite.com/commande/derniereEtape.aspx"... eh bien j'ai remarqué qu'il faut spécifier dans les paramètres d'Ogone l'url "www.monSite.com/page.aspx?type=commande&etape=derniereEtape" pour que cela fonctionne correctement, et non l'url "www.monSite.com/commande/derniereEtape.aspx", qu'il n'interprétera pas comme bonne url !!!

et ca je ne pige pas , car il me semblait que le but de l'url rewriting était de rendre uniquement visible les adresses rewritées, et il me semble que ce n'est pas le cas, d'après ces constatations... Ce qui m'amène à me poser cette question : si les sites externes voient notre site avec les URL non-rewritées, n'y a-t-il pas un risque que ce soient celles-là qui soient utilisées pour le référencement, et non les bonnes url rewritées ???

[CUCARACHA]

En fait, tu n'as aucun intérêt à rewriter l'url qui emmet puisque l'URL Rewriting est un dispositif qui permet de rentre intelligible les adresses ENTRANTES.

A la base c'était pour faciliter le travail de référencement des bots de référencement.

[CUCARACHA]

Pour éviter que les adresses non rewritées ne puissent être "vues" par les moteurs de recherche, il faut ajouter les adresses de pages non rewritées au robot.txt qui doit se trouver à la racine de ton site.

[nico_4802]

ben euh, oui mais bon, imaginons sur le site une page "références clients" :

"www.monSite.com/page.aspx?type=referencesClients"
rewritée en :
"www.monSite.com/referencesClients.aspx"

sur cette page, j'ajoute forcément des références clients, avec des liens vers les sites internet des clients.

imaginons que des internautes viennent sur mon site, et sont redirigés sur le site de mes clients via cette page, ce qui va générer du traffic sur le site de mes clients.

Lorsque ceux-ci vont voir les statistiques de fréquentation de leur site, et vont par exemple consulter la liste des lients pointant vers leur site... que vont-ils voir ? qu'il y a un lien vers leur site internet sur la page "www.monSite.com/page.aspx?type=referencesClients" ??? moi ce qui m'intéresserait, c'est qu'ils voient ma bonne url, càd qu'il y a un lien vers leur site sur la page "www.monSite.com/referencesClients.aspx" !!! et donc je souhaiterait que sur le net ne soient connues que mes url rewritées, et non les url standard...

est-ce que je me fais comprendre ?

[nico_4802]

Alors pour votre info :

pour ceux qui auraient déjà rencontré le problème ci-dessus (le fichier .browser du répertoire "App_Browsers" qui n'est pas pris en compte après compilation), après quelques bonnes heures de recherche, voici enfin la solution :

[CUCARACHA]

Dans mon cas, mais ça n'est peut-être pas la bonne pratique, je mets mes pages aspx dans un dossier /webpages.
Ce dossier est découpé en 3 ou plus
/Webpages/public
/Webpages/private
/Webpages/administration

Il devient beaucoup plus facile de gérer le robot.txt

Si tes pages rewritées sont à la racine et que robot.txt interdit le dossier /webpages, tu n'auras jamais tes .aspx référencées dans google.

++

Laurent