exemple-page-erreur-404

[Synology] Organiser ses services web personnalisés

Cet article a été rédigé il y a 5 années ! Il commence à dater, mais n'est pas forcément obsolète.. Lisez-le en gardant cela en tête !
Bonjour, bonjour ! Voici le complément de mon premier article sur la mise en ligne d’un dossier publique de partage (http://leblogdekzl.fr/?p=94) Il n’est pas nécessaire d’avoir suivi le premier tutorial pour comprendre cet article. Mon réseau suit une charte graphique, il faut me comprendre quand je tombe sur un site où la page d’erreur 404 est une page par défaut de l’hébergeur, je trouve ça niais. De la même façon une Table of /Index blanche, avec des icones par défaut, je trouve ça dommage,.. Alors pour remédier à ça, on va mettre en place une API Web contenant toutes les pages et les ressources qui permettront la personnalisation des services http. Voyez par exemple, cette belle page d’erreur : http://www.gauss-it.net/erreur404.html, remplaçant la page par defaut http://demo.synology.com/erreur404.html.

 I) ApiWeb :

Quand je parle de charte graphique, je parle par exemple de http://partage.gauss-it.net/apiweb/HEADER.html et http://partage.gauss-it.net/apiweb/README.html, servant à encapsuler la Table of /Indexhttp://partage.gauss-it.net/apiweb/itworks.html pour les services mis en places et non utilisés, etc.. Creez alors un dossier /volume1/@apiweb depuis votre terminal en SSH. Et mettez-y les fichiers que vous souhaitez partagez. Cette API Web me permet aussi biensur de ranger des fichiers .htaccess, comme ceux pour la création de réseaux intranet (http://leblogdekzl.fr/?p=130) Il me suffit alors simplement de créer un lien symbolique et tout baigne, un fichier à modifier pour 5 sous-domaines intranet.. Ça c’est de l’efficacité !! :o)

II) La mise en service

Il y a une chose délicate à comprendre et c’est ce qui m’a poussé à créer un service centralisé.. Le navigateur internet va toujours prendre la racine relative en fonction de l’URL que vous tentez d’accéder. (Normal elle est relative !) Concrètement ça veut dire que si vous souhaitez accéder au dossier /var/services/web/partage/, il y aura 2 façons d’y accéder (hors url locales) et aussi par conséquent 2 racines relatives à savoir :
  1. http://partage.example.org → /
  2. http://example.org/partage/ → /partage
Cela est capital à comprendre et très problématique dans les fichiers .htaccess, car en effet le fichier .htaccess prend donc la racine fonction de sa position dans l’arborescence.
  • À savoir, si vous mettez un .htaccess dans le dossier /var/services/web/ et que vous accéder à votre site via l’adresse http://example.org/partage, vous pourrez descendre dans l’arborescence ../ à savoir le dossier /var/services/web/.
  • Cependant si vous accédez à votre site via http://partage.example.org, vous ne pourrez par descendre à /var/services/web/ et vous resterez bloqué au dossier /var/services/web/partage/.
C’est la raison qui m’incite à utiliser des liens symboliques. Je lie le dossier /volume1/@apiweb/ à un dossier nommé apiweb dans le dossier courant (à savoir /var/services/web/partage, dans le cas précédant). Ainsi je suis sûr que j’aurai toujours accès à mes ressources quelque soit la position de la racine du .htaccess. Le fait que mes ressources soient centralisées ne me coûtent rien de plus en terme d’espace de stockage que le stockage de l’index des liens symboliques. Je n’ai rien d’autre à ajouter qu’un UNIQUE dossier contenant TOUT à la racine du sous domaine ! Que demander de plus ? 🙂 Par la suite, votre fichier .htaccess à la racine du sous domaine pointera des urls de la forme /apiweb/.. et rien d’autre puisque tout se trouve dedans ! Compléments : Si jamais vous souhaitez ajouter une sécurité de plus, je vous conseille de mettre dans le dossier "apiweb/" un fichier .htaccess avec le code suivant :
Deny from all
Ainsi personne n’aura accès au dossier depuis son navigateur, mais le dossier sera bel et bien utilisable

1. Table of /Index

Par exemple, pour personnaliser sa Table of /index, il suffit de mettre dans le dossier apiweb/ le fichier portant le nom suivant htaccess :
Options +Indexes RewriteEngine off IndexIgnore @eaDir apiweb IndexOptions +FancyIndexing +FoldersFirst +IgnoreCase +NameWidth=* +SuppressDescrip$ HeaderName /apiweb/HEADER.html ReadmeName /apiweb/README.html AddIcon /apiweb/ico/ico-html.png .html [..] AddIcon /apiweb/ico/ico-xml.png .xml DefaultIcon /apiweb/ico/ico-txt.png
Et je n’ai plus qu’à créer 2 liens symboliques à savoir
ln -s /volume1/@apiweb/ /var/services/web/partage/apiweb/ ln -s /volume1/@apiweb/htaccess /var/services/web/partage/.htaccess
Je reproduit ainsi la démarche pour chaque sous-domaine qui peut-etre accédé et voilà le travail !

2. Erreur 404

Pour la page 404 error, il suffit de créer une page sample.php dans le dossier apiweb et lancer la commande suivante :
mv /usr/syno/synoman/phpsrc/web/sample.php /usr/syno/synoman/phpsrc/web/sample.php.bak ln -s /volume1/@apiweb/sample.php /usr/syno/synoman/phpsrc/web/sample.php

3. Autres services complémentaires

Comme je l’ai expliqué dans cet article, on peut en profiter pour centraliser ses .htaccess pour intranet, pour les mdp pour éviter d’avoir des millions de .htpasswd ce qui n’est pas très sûr et en même temps si vous changez de mot de passe au moins le changement prend effet tout de suite !  

En résumé,

S’il y a une chose à comprendre c’est que les liens symboliques c’est super et ça rend beaucoup de services en évitant de copier en double, triple, etc.. ses données ^^

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *