+ Répondre à la discussion
Affichage des résultats 1 à 2 sur 2
  1. #1
    Membre confirmé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    janvier 2010
    Messages
    124
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gard (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Conseil

    Informations forums :
    Inscription : janvier 2010
    Messages : 124
    Points : 225
    Points
    225

    Par défaut URL Rewriting et WebDev

    Bonjour,

    L'objectif de cette discussion est de vous présenter différentes approches de l'URL Rewriting avec WebDev. Ces approches seront dépendantes et de la version de WebDev, et/ou du serveur Web utilisé 'Apache, IIS, etc...). Les solution s proposées sont loin d'être exhaustives et sans défaut, mais peuvent répondre à différents besoins et contraintes de déploiement (Serveur Web mutualisé, dédié, ...).

    Les solutions propres à WebDev.
    1. URL Courte

    La solution la plus simple et également la plus limitée, puisqu'elle ne propose que la possibilité de gérer une URL courte sur des pages dynamiques classiques WebDev.

    Vous connaissez tous l'habituel lien d'un site dynamique

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    http://www.monsite.com/WD160AWP/WD160AWP.EXE/CONNECT/MonSiteWeb
    Votre adresse pourra devenir, sans passer par une page html de redirection :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    http://monsite.com/MonSiteWeb
    L'apport est limité mais indéniable. Plus besoin de créer une page index manuel avec une redirection dedans.

    Limites et contraintes : WebDev 16 minimum, IIS 7 ou +, Apache 1.3, 2.2

    2. L'URL Rewriting WebDev.

    Reprenons l'exemple de l'aide en ligne, sachant qu'il est faux pour la plupart des déploiements :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    http://www.monsite.com/PAGE_FicheProduit.awp?Categorie=Voitures&Marque=Ferrari&Millesime=2008
    En fait, l'adresse sera plutôt ça :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    http://www.monsite.com/MonSiteWeb_WEB/FR/PAGE_FicheProduit.awp?Categorie=Voitures&Marque=Ferrari&Millesime=2008
    Avec le rewriting WebDev on peut obtenir ça:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    http://www.monsite.com/voiture-ferrari-2008.awp
    ou bien :
    http://www.monsite.com/ferrari/2008/voitures.awp
    ou plutôt, en étant réaliste :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    http://www.monsite.com/MonSiteWeb_WEB/FR/voiture-ferrari-2008.awp
    ou bien :
    http://www.monsite.com/MonSiteWeb_WEB/FR/ferrari/2008/voitures.awp
    On se rapproche d'une simplification correcte des pages. Vous pouvez vraiment régler les règles de réécriture des pages. Je vous laisse consulter l'aide en ligne qui est très claire la dessus :
    http://doc.pcsoft.fr/fr-FR/?2030054&name=URL_Rewriting

    Limites et contraintes : WebDev 15 minimum, IIS 5 ou +, Apache 1.3, 2.2 - ATTENTION : Ne fonctionne pas sous Apache 2.0
    Une solution externe : IIRF

    Cette solution est une solution permettant d'appliquer un principe d'url rewriting quasi identique au système Apache.
    D'autres solutions existent bien sur, mais celle ci à l'avantage d'être gratuite, très complète et légère.
    Comme la plupart des autres solutions sous IIS, IIRF fonctionne comme un filtre ISAPI . D'ailleurs, son nom complet est très clair : Ionics Isapi Rewrite Filter

    Vous pouvez le télécharger et trouver toutes les infos utiles ici :
    http://iirf.codeplex.com/

    L'installation est très simple et bien documentée dans l'aide. Je n'ai pas rencontré de difficultés dans la mise en oeuvre.
    Pour activer IIRF sur un site Web, il faut l'ajouter aux filtres ISAPI du site web voulu. Ajouter un nouveau filtre et donnez lui un nom clair (IIRF ou URL Rewrite) et pour l’exécutable, allez pointer sur la DLL IIRF.dll qui se trouve dans le répertoire bin de votre installation IIRF.

    Désolé de ne pas être plus clair, mais entre les différentes versions de IIS, la procédure et les écrans pour ajouter un filtre ISAPI sur un site peuvent être très différentes, même si elles restent très simple. Référez vous à l'aide de IIS sur l'ajout de filtre ISAPI.

    Le paramétrage du rewriting se fait ensuite par fichiers INI, placés dans les répertoires du site qui utiliseront des règles de rewriting.
    Cela ressemble énormément au fonctionnement des .htaccess des serveurs Apache.

    Vous créez un fichier appelé IIRF.ini par répertoire du site dans lequel on veut gérer l'URL rewriting.
    Sur un site WebDev, cela va nous intéresser sur le répertoire racine, par exemple pour éviter de gérer une page de redirection, dans le répertoire MonSiteWeb_WEB/FR et/ou les autres langues.

    Ensuite chaque fichier INI va remplir son role. Un exemple :
    Le fichier INI du répertoire racine :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    # Regles de réécriture pour MonSiteWeb.com
    # Fichier de paramétrage pour la racine du site
    #
    # Ce fichier DOIT être placé dans le répertoire racine (NOMDUSITE)
    #
    #    Date de MAJ : 8/11/2010
     
    RewriteLogLevel    1
    RewriteLog     c:\inetpub\iirfLogs\iirf   
    RewriteEngine     ON
    StatusInquiry     ON
    RewriteBase     ON
    #IterationLimit    5
    Redirection pages awp - Penser à rediriger ici toutes les pages déclarées dans le répertoire AWP pour avoir un lien court.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    RedirectRule ^/MonTest-(.*)$  /MonSiteWeb_WEB/FR/MonTest-$1             [I]
    Ici, un exemple de redirection vers le répertoire FR du site, et dans ce répertoire, on aura une réécriture d'adresse.
    Ex : http://www.monsite.com/MonTest-1 renvoie vers http://www.monsite.com/MonSiteWeb_Web/FR/MonTest-1

    Redirection vers un répertoire contenant par exemple des documents rangés dans un sous répertoire spécifique (ici 2 parametres :le nom du client, puis le document)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    RedirectRule ^/VoirDocument/(.+)-(.+)$ /DonnéesClient/$1/Documents/$2        [I]
    ex : http://www.monsite.com/VoirDocument/...nTel-Tarif.pdf renvoie vers http://www.monsite.com/MonSiteWeb_Web/DonnéesClient/ClientUntel/Tarif.pdf

    Transformer une adresse dynamique
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    RewriteRule ^/Entreprise-(.+)$ /WD150AWP/WD150AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=$1 [L,I]
    Ex : http://www.monsite.com/Entreprise-ClientUnTel devient
    http://www.monsite.com//WD150AWP/WD1...se=ClientUnTel
    Liens anciennes versions... Si votre site a de nombreuses années et a diffusé des liens sous d'anciennes versions, vous êtes couvert!
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    RewriteRule ^/WD140AWP/WD140AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=(.+)$ /WD150AWP/WD150AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=$1 [L,I]
    RewriteRule ^/WD120AWP/WD120AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=(.+)$ /WD150AWP/WD150AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=$1 [L,I]
    RewriteRule ^/WD110AWP/WD110AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=(.+)$ /WD150AWP/WD150AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=$1 [L,I]
    RewriteRule ^/WD100AWP/WD100AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=(.+)$ /WD150AWP/WD150AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=$1 [L,I]
    Ensuite, pour être cohérent dans mon exemple, le fichier IIRF.ini placé dans le répertoire FR en lien avec les instructions passées dans le fichier ini du répertoire racine.

    IIRF.ini

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    # Règles de réécriture 
    RewriteLogLevel 1
    RewriteLog     c:\inetpub\iirfLogs\iirf
    RewriteEngine     ON
    StatusInquiry     ON
    RewriteBase     ON
    #IterationLimit    5
     
    #Réécriture des adresses...
     
    #Adresses de consultation de profil
    RewriteRule ^/MonTest-(.*)$ /Consulter_Profil.awp?p1=$1         [L,I]
    Cette réécriture appelle la page awp Consulter_Profil.awp. ce qui donnerai sous forme d'URL :
    http://www.monsite.com/MonTest-1 <==> http://www.monsite.com/MonSiteWeb_We...rofil.awp?p1=1

    Pas mal, non?

    Voilà , il y a beaucoup d'autres possibilités dans IIRF, je vous laisse le soin de consulter les fichiers d'exemples et la documentation. Il existe également d'autres solutions qui fonctionnent très bien. Il est clair que IIRF ne peut être mis en oeuvre que sur vos serveurs ou serveurs dédiés. Certains hébergeurs comme Kalanda proposent une solution qu'ils intègrent dans leurs serveurs mutualisés et qui ressemble beaucoup à cette solution dans la mise en oeuvre (même principe que le .htaccess d'Apache.)


    Limites et contraintes : IIS 5 ou +(pas testé en dessous), Serveur dédié ou hébergeur mutualisé acceptant l'ajout de scripts ou programmes.

    Je vous laisse libre d'apporter vos commentaires et autres solutions sur cette contribution qui, comme je le disais au départ, est loin d'être exhaustive et ne demande qu'à être enrichie.

    Cordialement,

    Laurent B.

  2. #2
    Membre Expert
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 230
    Détails du profil
    Informations personnelles :
    Âge : 29
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : mai 2004
    Messages : 1 230
    Points : 1 672
    Points
    1 672

    Par défaut

    Bonjour,

    Je rebondis sur la solution IIRF que je viens d'implémenter.
    C'est assez simple du moment qu'on suit le tuto d'install et de config à la lettre, par contre je conseille de valider toutes les étapes comme indiqué dans le configuration manuelle.

    Le contexte et le problème :
    On a des pages applicatives situées dans un sous-site d'un site Sharepoint 2007, tournant sur un IIS6. Ceci crée une arborescence assez disgracieuse.
    Contrairement à un site pur IIS, il n'est pas possible de créer un site de type "racine" si l'arborescence n'est pas en filesystem. C'est un inconvénient de Sharepoint, heureusement on a la solution de la réécriture (un reverse proxy aurait pu faire l'affaire également).

    Le cas d'utilisation de ma réécriture est le suivant :
    Des utilisateurs mobiles au sein de l'entreprise souhaitent accéder rapidement à ces pages. Des utilisateurs itinérants se connectent via leur mobile au travers d'une passerelle qui, pour simplifier ses règles de filtrage, requiert une url simple. Pour cela, je crée une entrée dns (interne) pointant vers mon serveur IIS.

    En gros, on va faire un genre d'obfuscation du nom d'hôte + arborescence pour faire croire à la passerelle qu'on a un site de type racine.

    Exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    navigateur utilisateur : 
    http://monsitemobi.domaine/ , 
    page exécutée en réalité :
    http://serveursharepoint.domaine/sites/monsoussite/mobi/default.aspx
    Peut de conditions/règles suffisent à implémenter ceci. Il y a encore des cas que je dois tester, mais grosso modo ça donne :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    RewriteEngine ON
    RewriteCond %{HTTP_HOST} ^monsitemobi\.domaine$
    RewriteRule ^[\/](\?){0,1}$  	    /default.aspx
    RewriteRule (.*)$   /sites/monsoussite/mobi$0   [L]
    L'intérêt principal de la solution : le filtre ISAPI iirf se lance avant celui d'asp.net. Ainsi, nous ne sommes pas limités dans nos redirections (plusieurs solutions existantes dépendent du filtre isapi asp, limitant le type de pages interceptées).

    Autres avantages :
    - pas de redémarrage du serveur,
    - les règles sont rechargées en fonction de la date de dernière modification du fichier ini,
    - niveaux de log acceptables (paramétrables) pour un environnement de prod,
    - les erreurs sont administrables (event viewer) dans le cas où les logs ne suffisent pas,
    - un module de test de vos redirections sous la forme d'un exécutable console permet de valider vos redirections.

    Pour peu que les urls internes de vos pages/liens/ressources soient rédigées avec un path relatif au root, vous n'avez rien à changer.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •