1. Définition du besoin 1Définition de l'objet

BABINOT Julien, FRIETMAN Maxime, GEANDREAU Emeric
STESIO

Historique des révisions

Date	Version	Description	Auteur
18/09/2014	1.0	Affichage des médicaments	BABINOT Julien GENDREAU Emeric FRIETMAN Maxime
9/10/2014	1.1	Modification des médicaments	/
13/11/2014	2.0	Ré-organisation des répertoires	/

Table des matières

1. Définition du besoin 3

1.1 Définition de l'objet 3

1.2 Forme de l'objet 3

2. Contraintes 3

2.1 Ergonomie 3

2.2 Environnement 3

3. Architecture 4

3.1 Affichage 5

3.2 Modification de la base de données 5

3.3 Connexion 5

3.4 Mot de passe oublié 6

4. Extraits de code 6

4.1 Affichage des médicaments 6

4.2 Modification des médicaments 9

4.2.1 Modification 10

4.2.2 Insertion 11

4.2.3 Suppression 11

4.3 Connexion 12

4.4 Mot de passe oublié 12

5. Conclusion 12

1.Définition du besoin

1.1Définition de l'objet

Il y a différents types d’utilisateurs qui ont des rôles distincts :
Les visiteurs : utilisateurs externes, qui ne peuvent que consulter les médicaments.
Les techniciens : mettent à jour la base de données.

1.2Forme de l'objet

L'application doit permettre aux visiteurs, au travers d’une interface web, de consulter les médicaments et aux techniciens de télécharger un fichier xml de mise à jour.

2.Contraintes

2.1Ergonomie

La(les) page(s) web devront avoir une vocation métier et productivité. On limitera donc tous les éléments graphiques superflus (pas de menu animé, pas de module flash).

On pourra améliorer ou contrôler l'interface utilisateur par du code Javascript.

Le code HTML est séparé du code PHP via le moteur de gabarit Smarty.

2.2Environnement

Le langage utilisé sera le php.

L’architecture du code produit doit respecter les conventions d’usage : développement basé sur des bibliothèques de fonctions.

On prendra soin de séparer au maximum le rendu utilisateur de la logique interne de l'application.

3.Architecture

3.1Affichage

3.2Modification de la base de données

La structure de la table des médicaments a été modifiée. On a ajouté deux colonnes : MED_DELETED et MED_DATEMAJ pour avoir, pour chaque médicament, les informations suivantes :

- Le type de mise à jour effectuée (suppression du médicament, modification de certaines données, ajout d’un nouveau médicament)

- La date de la mise à jour

En effet, on ne souhaite pas qu’un médicament qui n’est plus vendu soit complètement supprimé de la base de données. Par contre, conserver l’information sur la date de suppression permettra de purger annuellement la base de données.

3.3Connexion

La connexion se fait via un annuaire LDAP. Les identifiants saisis sont stocké en sessions puis vérifiés à chaque début de page (via un fichier checkmdp.php).

3.4Mot de passe oublié

Le mot de passe oublié renvoie vers un formulaire où l'on saisi le nom d'utilisateur. Ce formulaire appelle le fichier newPass.php.

Ce fichier a pour but :

• 
  Générer un nouveau mot de passe aléatoire de 15 caractères
  
• 
  Vérifier l'existence de l'utilisateur lié au login saisi (et chercher son adresse email stockée dans l'annuaire LDAP)
  
• 
  Modifier son mot de passe
  
• 
  Lui envoyer un mail avec le nouveau mot de passe
  

4.Extraits de code

4.1Affichage des médicaments

Dans le fichier de traitement « medic_show.php », on vérifie tout d’abord s’il s’agit du premier chargement de la page en vérifiant si $_POST['med'] est défini ou non.
Si c’est le premier chargement de page, on sélectionne le premier médicament.

Sinon on vérifie si il faut le précédent ou le suivant. On obtient cette information via les formulaires des boutons suivant et précédent.
Les boutons suivant et précédent sont dans deux form séparés qui ont chacun un input caché de nom « method » qui prend la valeur « next » ou « prev », ainsi qu’un deuxième input caché contenant l’identifiant du médicament actuellement affiché. Ces inputs sont utilisés dans le cas de l'échec de la fonction javascript que l'on appelle dans le onsubmit.

Exemple pour le bouton suivant :

La fonction en question ( show() ) :
On commence par créer une requête XMLHttpRequest avec laquelle nous allons envoyer les données normalement envoyées par le formulaires dans le format x-www-form-urlencoded pour que le traitement s'effectue de la même manière qu'avec un formulaire POST.
function show(direction) {

var r = new XMLHttpRequest();

r.open("POST", "medic_show.php", false);

r.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");

r.setRequestHeader("Accept", "application/json");

var depolegal = document.getElementById("depotLegal").innerHTML;

r.send('med='+depolegal+'&method='+direction);
Afin de déterminer si nous appelons le fichier php via un appel AJAX, nous vérifions le header de la requête HTTP. Si le paramètre ACCEPT contient « application/json », alors seules les données sont envoyées et la page n'est pas rechargée :
if (split(';', $_SERVER['HTTP_ACCEPT'])[0] == 'application/json') {

header('Content-Type: application/json');

echo json_encode($data);
La réponse nous renvoie les informations du médicament au format JSON avec lesquelles nous modifions le DOM.
if (r.status == 200) {

var data = JSON.parse(r.responseText);

document.getElementById("depotLegal").innerHTML = data.MED_DEPOTLEGAL;

document.getElementById("nomCommercial").innerHTML = data.MED_NOMCOMMERCIAL;

document.getElementById("famille").innerHTML = data.FAM_LIBELLE;

document.getElementById("composition").innerHTML = data.MED_COMPOSITION;

document.getElementById("effet").innerHTML = data.MED_EFFETS;

document.getElementById("contreIndic").innerHTML = data.MED_CONTREINDIC;

document.getElementById("prixEchantillon").innerHTML = data.MED_PRIXECHANTILLON;

return false;

} else {

return true;

}
Via php, nous sélectionnons le médicament suivant ou précédent (en fonction du champ « method » dans $_POST) 

Ex : code pour le suivant :
if ($_POST['method'] == 'next'){

$req=$cnx->prepare("select MED_DEPOTLEGAL FROM MEDICAMENT WHERE MED_DEPOTLEGAL>? AND MED_DELETED = 0 ORDER BY MED_DEPOTLEGAL LIMIT 1;");

$req->execute(array($_POST['med'])); //selection MEDICAMENT suivant

if(!($rep=$req->fetch())){

$req=$cnx->query('select MED_DEPOTLEGAL FROM MEDICAMENT WHERE MED_DELETED = 0 ORDER BY MED_DEPOTLEGAL LIMIT 1;');

$rep=$req->fetch(); //Si il n'existe pas, premier medicament

}

} […]

$recordset=$cnx->prepare("select * FROM MEDICAMENT JOIN FAMILLE ON MEDICAMENT.FAM_CODE=FAMILLE.FAM_CODE WHERE MED_DEPOTLEGAL=?;");

$recordset->execute(array($rep['MED_DEPOTLEGAL']));
Si le dernier médicament est atteint, on revient à l’autre bout de la liste (deuxième if cf. exemple)
Une fois le médicament à afficher sélectionné, on réceptionne les données via :

$data=$recordset->fetch();
On peut ensuite afficher le médicament en mettant les données en paramètre de Smarty.

4.2Modification des médicaments

La mise se fait via un fichier XML, que l’on charge grace à cette fonction :

$xml = simplexml_load_file('medicament.xml');

Le fichier XML fournit pour la mise à jour ne contient pas toujours le même nombre de médicament. Nous récupérons le nombre de données à modifier et/ou à ajouter via :

$nbElements=$xml->count();
Pour chaque élément à modifier :

for ($i=0;$i<$nbElements;$i++)

{

$bigtab = array();

On récupère le nom de la table à modifier

$table = addslashes(strtoupper($xml->table[$i]->attributes()['name']));

On récupère l’action a faire via son attribute appelé ‘action’

$action = $xml->table[$i]->attributes()['action'];

On initialise et on remplit les tableaux qui contiennent les champs à modifier et leurs valeurs

$champs = array();

$champsval = array();

foreach($xml->table[$i]->children() as $column) {

$champs[] = (string)$column->attributes()['name'];

$champsval[(string)$column->attributes()['name']] = $column;

}

…
On construit ensuite les requêtes en parcourant ces tableaux :
Pour une action spécifique, nous construisons une requête SQL. Nous ajoutons ou modifions à chaque fois la propriété MED_DATEMAJ, qui permet de garder une date de la dernière mise à jour. Le jour est stocké dans la variable $date via la ligne suivante :

$date=date("Y-m-d");

4.2.1Modification

case 'updated':

$requete = "update {$table} SET";

$where = " where";

foreach($champs as $index){

if ($index=="MED_DEPOTLEGAL") {

$where .= " $index = :$index;";

} else {

$requete .= " $index = :$index,";

}

$bigtab[$index]=$champsval[$index];

}

$requete = substr($requete,0,-1);

$requete .= $where;

$update = $cnx->prepare($requete);

$update->execute($bigtab);

break;
Nous construisons la requête update avec la table indiquée dans le fichier XML. (medicament normalement). L’identifiant n’étant pas modifié mais plutôt utilisé pour savoir quel médicament modifier. Les autres propriétés sont entrées après le SET (ex : MED_NOMCOMMERCIAL = :MED_NOMCOMMERCIAL ; en faisant attention aux « : ». En effet, :MED_NOMCOMMERCIAL sera remplacé par la valeur du tableau $bigtab ayant pour index MED_NOMCOMMERCIAL).

Le substr à la fin sert à effacer la virgule en trop, engendrée par la boucle.

4.2.2Insertion

case 'inserted':

$requete = "insert into {$table}(";

$values = "";

$params = ") Values(";

foreach($champs as $index){

$requete .= $index.',';

$bigtab[$index] .= $champsval[$index];

$params .= ":{$index},";

}

$requete = substr($requete, 0, -1);

$params = substr($params, 0, -1);

$params .= ');';

$requete .= $params;

$insert = $cnx->prepare($requete);

$insert->execute($bigtab);

break;
La construction de la requête est construite sous le même principe. Soit la requête INSERT INTO $table (1) VALUES (2) ; les index de la table $bigtab sont placés dans les parenthèses 1, et ses valeurs sont placées dans les parenthèses 2.

Même fonction des substr.

4.2.3Suppression

case 'deleted':

$requete = "update {$table} SET MED_DELETED = 1, MED_DATEMAJ = '{$date}' where MED_DEPOTLEGAL = ";

$requete = "'".addslashes($champsval['MED_DEPOTLEGAL'])."';";

$cnx->query($requete);

break;
La suppression d’un médicament n’engendre pas de suppression dans la base de données. La propriété MED_DELETED prend juste la valeur 1, qui signale que le médicament à été supprimé.

4.3Connexion

Dans le fichier checkmdp.php, nous vérifions d'abord si une session est créée. Si elle n'est pas créée, cela signifie que l'utilisateur est en train de se connecter. Nous vérifions donc l'existence des valeurs de POST, et nous créons la session avec ces valeurs.

Nous effectuons ensuite un ldap_bind sur l'annuaire avec ces identifiants. Si le bind échoue, l'utilisateur est redirigé vers l'index. Sinon, la page dans laquelle nous appelons checkmdp.php continue son exécution.
La déconnexion se résume à détruire la session.

4.4Mot de passe oublié

Génération du mot de passe :

On parcours 15 fois une boucle pour construire une chaine de 15 caractères, en ajoutant à un chaine un caractère aléatoire à chaque boucle (avec la fonction rand() ).
On vérifie l'existence de l'utilisateur en parcourant l'annuaire LDAP en étant connecté via un compte disposant des droits nécessaires.

S'il existe, on crée le mail et on l'envoie via la fonction mail() de php. Ensuite, on modifie le paramètre unicodepwd qui correspond au mot de passe de connexion dans le tableau $userdata (qui ne contiendra que cet élément) puis on modife l'utilisateur en lui injectant ce tableau.
$entry = ldap_first_entry($ldap, $search);

$dnareset = ldap_get_dn($ldap, $entry);
$userdata["unicodepwd"] = mb_convert_encoding($pass, "UTF-16LE");

if(!(ldap_mod_replace($ldap, $dnareset, $userdata))) die("Echec : Impossible de changer le mot de passe");

$valid = 'true';

5.Conclusion

Les modifications de la base de données sont fonctionnelles (l’ajout, la suppression et la modification). L’affichage l’est également.

Page : /