SP1 STAGE 2 | portfolio

STAGE 2 - SP1 CRÉATION D'UN SERVEUR WEBDAV

Retour Stage 2

Alter-Info est une entreprise de prestataire informatique.

L'application Réagir est une application créée par cette entreprise afin de simplifier le travail des employés d'entreprises tels que Pôle Emploi ou autres prestataires privés.

Cette application sert entre autres à la création d'un agenda automatisé et à la complétion automatique des différents documents que l'employé doit rendre. Cette fonction a pour but final d'éviter les redondances dans le travail.

Les utilisateurs de cette application auront pour fonction d'assurer l'insertion professionnelle des différents demandeurs d'emplois dont ils ont la charge.

Contexte

Ce qui nous intéresse dans cette application, c'est sa fonction agenda, une fonction que d'autres prestataires n'ont pas. Donc, une fonction à approfondir.

Cette fonction agenda n'est pour l'instant reliée à rien, ce que l'on voudrait, c'est pouvoir la lier à un logiciel de gestion d'agendas tel que Outlook ou Google Calendar.

Également, il faudrait pouvoir consulter son calendrier directement depuis un site web sans avoir à s'inscrire sur Google ou Outlook.

Besoin

Les technologies utilisées ont été :

Technologie(s) utilisée(s)

J'ai énormément appris en ce qui concerne Linux, je ne suis plus si réticent quant à son utilisation.

En ce qui concerne PHP, j'ai pu me rendre compte de la difficulté que peut être l'intégration d'un service dans un site WEB. Surtout si ce service n'est plus maintenu et non commenté.

ça m'a notamment permis de me rendre compte de l'importance des commentaires dans un code. surtout dans un si gros projet.

Le service que j'ai développé avec tout mon cœur est disponible

ici : http://alterinfo-services.fr/

Une fois dans le service WebDav (celui qui affiche le formulaire), je vous recommande d'utiliser

ce lien de calendrier : http://alterinfo-services.fr/webdav/demonstration.ics

Bilan

Ubuntu 16.04

Serveur :

- Apache2

- WebDav

- FTP

Langage de programmation utilisé :

- Bash

- PHP 5.6

- HTML

- CSS

Pour cette SP, j'ai donc utilisé plusieurs serveurs. Ici, je vais expliquer à quoi sert le serveur et comment je m'en suis servit.

Utilisation des serveurs

1 - Le serveur Apache

Pour commencer, qu'est-ce qu'un serveur Apache ?

Un serveur Apache est un serveur Web. On peut donc dire que c'est le centre d'un serveur qui va avoir une interface Web. En l’occurrence, on veut une interface WEB donc on veut un serveur Apache. L'avantage de Linux, c'est que contre toute attente, il est simple et très rapide à installer. Une seule commande suffit :

apt-get install apache2

L'installation se fait normalement et le service est disponible instantanément (en local seulement pour l'instant).

2 - Le serveur WebDav

Maintenant qu'on a présenté le serveur Apache, il est tant de présenter son fils : Le serveur WebDav. Le WebDav est une alternative au FTP passant par le port 80 (protocole HTML). Celui-ci à l'avantage de permettre le transfert d'une cible vers une autre sans avoir à créer de dossier "temporaire" sur la machine qui entreprend le déplacement.

Encore une fois, il est pas bien compliqué à installer et configurer :

a2enmod dav

a2enmod dav_fs

Suite à ça, viens une légère modification à apporter à un des fichiers configuration du serveur Apache afin d'indiquer à celui-ci si il doit utiliser le WebDav, avec quelle sécurité et dans quel répertoire.

On peut trouver le fichier config ici : /etc/apache2/sites-available/000-default.conf

Après modifications voici à quoi il devrais ressembler :

DavLockDB /var/www/DavLock

ServerAdmin webmaster@localhost

DocumentRoot /var/www/html

ErrorLog ${APACHE_LOG_DIR}/error.log

CustomLog ${APACHE_LOG_DIR}/access.log combined

Alias /webdav /var/www/webdav

DAV On

</Directory>

</VirtualHost>

Cette configuration autorise le WebDav dans le répertoire situé : /var/www/webdav

Il y a trois autres lignes à ajouter si on veut obliger l'utilisateur à donner un nom d'utilisateur et un mot de passe pour se connecter à la session WebDav. Nous n'avons pas opté pour ce type d'authentification car il serait trop contraignant pour les utilisateurs.

Exemple de configuration en mode Digest (Utilisateur et Mot de Passe Obligatoire)

DAV On

AuthType Digest

AuthName "webdav"

AuthUserFile /etc/apache2/users.password

Require valid-user

</Directory>

Le WebDav nous sert à plusieurs choses :

- Stocker des calendriers et autoriser les clients à les télécharger (en spécifiant l'URL du calendrier dans le navigateur)

- Lier des logiciels d'agenda (Outlook, Google Calendar ou autre) avec des calendriers créé par d'autres applications (les bons services d'agenda peuvent se synchroniser avec des serveurs WebDav/CalDav)

J'ai pas de capture d'écrans pour le serveur WebDav, mais des précisions viendrons plus tard.

3 - Le serveur FTP

Le serveur WebDav permet l'envois de fichiers sur le serveur, mais comme nous avons opté pour une version WebDav pas très sécurisé, j'ai préféré utiliser un serveur FTP (vsftpd plus précisément car c'est une version très facile à installer et pourtant très sécurisé. Pour l'instant, aucune faille majeur n'a été détecté et la plupart des failles trouvées ont rapidement été bouchées). De ce fait, l'application Réagir se connectera au serveur d'une manière sécurisée.

Pour installer le serveur FTP : Rien de plus simple que apt-get install vsftpd

Honnêtement, j'ai pas grand chose à dire sur cette partie de la SP. Tout le monde sait ce qu'est un serveur FTP (Transfert de donnée) et j'ai pas vraiment eu besoin de le configurer à part remplacer 'NO' par 'YES' sur une ligne qui interdit quiconque d'écrire sur le serveur FTP.

On en a donc terminé avec les serveurs. Il faut savoir qu'a ce moment là, même si le serveur est hébergé en local, il est fonctionnel. Enfin... pas tout à fait

//Passage à la catégorie 'scipt'

Maintenant que le serveur fonctionne, presque tout est bon.

En effet, il reste un léger problème : les données envoyées par l'application via le serveur FTP ont très peu de permissions : Lecture/écriture pour le propriétaire, Rien pour les autres.

C'est problématique n'est-ce pas ?

J'ai donc créé un script afin de remédier au problème

Catégorie 'script'

Le script

De cette façon, je met à jour les permissions dès que le nombre de fichiers présents dans le répertoire change. De plus, chaque soir à minuit, je supprime tous les documents qui n'ont pas '.ics' comme extension (hormis index.html et le répertoire phpCalendar)

Voici la dernière partie de cette SP. C'est aussi je dirais la partie qui m'a le plus fait souffrir.

Il s'agit de l'affichage des calendriers en version WEB. Un utilisateur qui n'est client d'aucun service de messagerie permettant la création et la visualisation d'Agenda/Calendrier se retrouve bien embêtée pour consulter son agenda généré par l'application Réagir (qui est une application lourde). On a donc voulu créer un moyen de les consulter directement via un site-web (de préférence le site qui les héberge).

La cerise sur le pudding

On se souvient que l'installation de ce serveur à demandé l'installation du serveur Apache. Il serait donc bon de l'utiliser. Pour cela j'ai mené mes petites recherches et je suis tombé sur une relique du passé appelé "phpicalendar".

Chance sur moi, c'est pile ce qu'il me faut : un moyen de visualiser des calendriers grâce à la technologie PHP.

Malchance sur moi : ça fais 10 ans que le répertoire n'a pas été mis à jour.

Bien évidemment, les dernière technologies et PHP7 ne sont pas compatibles avec celui-ci. Et bien évidemment, PHP5.6 n'est pas disponible dans les repository d'Ubuntu 16.04.

J'ai donc continué ma petite recherche puis je suis tombé sur un moyen simple d'installer PHP5.6 sur Ubuntu16.04 en utilisant un repository 'annexe'

Premièrement : Ajouter le repository :

sudo add-apt-repository ppa:ondrej/php

Ensuite : Appliquer les changements :

sudo apt-get update

Après ça : Installer PHP5.6 :

sudo apt-get install php5.6

Finalement : Intégrer le module PHP5.6 dans Apache

a2enmod php5.6

Une fois ça fait, viens la tourmente : L'intégration de phpicalendar dans mon site.

Le problème est pas tant l'intégration au final. Le problème, c'est surtout le fait de faire transiter les informations de mon formulaire jusqu'au fichier config de phpicalendar.

(Normalement, on doit spécifier à la main quels sont les calendriers à afficher, et cette donnée n'est pas censé être modifié)

J'ai donc opté pour un fichier .txt dans lequel serait écrit l'adresse vers le calendrier qu'on souhaite afficher.

Le problème c'est qu'avec cette façon, une seul personne peut afficher son calendrier à la fois. Si un autre utilisateur souhaite afficher son calendrier, l'URL de son calendrier viens s'écrire dans le fichier texte et écrase celle du client précédent. Cette option n'es donc pas viable.

C'est pourquoi j'ai continué à chercher et ce pendant un bon moment.

Au final, j'ai découvert les Cookies. Plutôt utile et unique à l'utilisateur. Cette découverte à été si bénéfique et m'a tellement inspiré que j'en ai profité pour développer dans le formulaire un moyen d'entrer plusieurs liens de calendrier afin d'en afficher plusieurs en même temps. De cette façon, je rentre mes calendriers dans le formulaire, j'arrive sur une page qui traite les données, les sérialise et les met dans un cookie. Finalement, une fois arrivé dans le fichier config (là ou on est sensé avoir entré l'URL des calendriers à la main) je récupère les données de mon Cookie, je les 'déserialise' et les met dans un Array().

De cette façon, je suis capable d'afficher un ou plusieurs calendriers.

De toute manière, j'ai pris des photos :

Le script en exécution

Il y a aussi d'autres vues (vue jour, semaine, mois, année) et une version "printer-friendly" qui affiche tout dans une liste. Comme vu ci-dessus : On peut combiner plusieurs calendriers afin de faire un "calendrier d'équipe" très utile pour réaffecter des rendez-vous en cas d'absence.