Protéger par un formulaire toutes les IHM d'une même session php

pierrot35 · 16-08-2014 11:12:18

Bonjour,

Je cale sur ceci :
J'ai un dossier "origine.php", ce dossier contient des fichiers .php comme ci dessous :
http:// www.xxxxx.fr/origine.php/
- index.php
- formulaireaccess.php
- page1.php
- page2.ĥp
- ..

Voila les codes php du formulaireacces, de l'index.php et des autres pages

Codes Formulaireaccess

<?php

session_start();

define('LOGIN','toto');

define('PASSWORD','tata'); 

if(isset($_POST['login'], $_POST['password']))

{

    if($_POST['login'] === LOGIN && $_POST['password'] === PASSWORD)

    {

          $_SESSION['login'] = true;

      header("Location: index.php");

          exit;

    }

}

?>

<html>...</html>

Code index.php du dossier origine

<?php

session_start();

if(!isset($_SESSION['login']))

{

    header("Location: formulaire.php");

    exit;

}

?>

<html>...</html>

code autres pages

<?php

include_once("check_formulaire.php");

?>

(re) Tout les fichiers php sont dans le même dossier "origine"

Mon problème :
si je lance les URL.php de origine.php ou index.php, tout va bien, mon formulaire s'active et demande id et Mdp.
Par contre, si je lance les URL(s).php des autres pages ( ex page1.php), j'arrive directement sur son IHm sans passer par le formulaire, donc plus de sécurité.

A prirori le "include_once("check_formulaire.php");" n'est pas activé , je comprends pas ce qui se passe, ou est mon erreur ,
Merci de coup de main , je suis loin d'être un expert Php..

cdlt
pierre

pierrot35 · 16-08-2014 11:16:47

juste une petite correction dans les codes, il faut remplacer formulaire.php par formulaireacces.php, j'ai fait une erreur de copiage ( mauvais fichier), excusez moi

Maljuna Kris · 16-08-2014 18:15:32

Saluton,

Y-a-t-il aussi erreur sur le nom du fichier en include_once ?

Jc · 17-08-2014 07:40:53

Bonjour,

Présenté ainsi,

include_once("check_formulaire.php");

doit être un fichier "vide" puisque le premier fichier s'appelle formulaireaccess.php (c'est pas dit comme ça, mais pierrot s'exprimant très clairement, je ne peux que supposer). Donc du coup c'est normal que le formulaire de connexion ne soit pas chargé.

Donc Mk, normalement la réponse à ta question est oui

++

pierrot35 · 17-08-2014 11:26:46

Bonjour, et merci de vos contacts, j'en ai bien besoin,

oui, il y a aussi la même erreur dans "include_once", sans erreur le code est donc :
<?php
include_once("check_formulaireacess.php");
?>

J'ai pas compris pourquoi Jc indique que c'est normal que le formulaire de connexion ne soit pas chargé ? je ne suis plus.. je ne dois rien mettre dans include_one ==> include_once(), c'est ça ?
Ce qui ferait :
<?php
include_once("check_()");
?>

pierrot

Jc · 17-08-2014 11:55:33

Bonjour,

Désolé d'avoir apporté de la confusion dans mes propos, cela n'était pas mon intention.

Vu ta réponse, il faut pour résoudre ton problème que ce code là:

<?php

session_start();

if(!isset($_SESSION['login']) || $_SESSION['login']!=='true'){ header("Location: formulaireaccess.php"); exit;}

?>

se trouve dans toutes tes pages (page_1.php, etc...)

Attention pour que le petit rajout que j'ai fait fonctionne il faut que tu rajoutes des simples quotes à true dans formulaireaccess.php : $_SESSION['login'] = 'true';
Après c'est pas suffisant pour appeler cela "sécurisé" mais pour assurer le minimum syndical dirons-nous.

Bon dimanche

Dernière modification par Jc (17-08-2014 15:06:46)

pierrot35 · 17-08-2014 15:53:42

Merci bien, bon dimanche à toi aussi
pierrot

pierrot35 · 17-08-2014 16:35:24

CA MARCHE impeccablement !!!
Est ce que je peux me permettre de recontacter sous huitaine ou plus concernant une meilleure sécurisation ?
Je vais m'atteler à un autre sécurisation avec Mysql.
Quoiqu'il en soit, je comprendrai si tu étais trop occupé, c'est déjà beaucoup ton coup de pouce, et MERCI ENCORE
pierrot

Jc · 17-08-2014 22:04:57

Bonjour,

Merci à toi pour ton retour, ils sont rares ici, et ça fait toujours plaisir.

pierrot35 · 16-09-2014 10:54:30

Bonjour,

me voila de nouveau avec une nouvelle difficulté, la 1ére partie du sujet précédent est Ok et fonctionne toujours parfaitement.

J'ai entrepris de passer à un "échelon supérieur" en me connectant à un Bdn Mysql qui contient login et mot de passe, crypté en sha1, l'observation trés juste de Jc concernant le minimum syndical en terme de protection m'a engagé dans cette évolution. Je tiens encore ici à remercier Jc pour son aide.
Je me suis trés trés largement inspiré d'un tuto vidéo, mais je ne sais pas si je peux mettre le lien ici ?

Donc voilà maintenant ma difficulté :

Apartir d'un site public, je pointe sur une session sécurisée qui contient plusieurs pages privées ( pageprivee1.php, pageprivee2.php, ..).
Ce lien dirige vers un formulaire de login + mot de passe (sha1) déjà enregistrés dans ma Bdn Mysql.

Les codes du fichier login.php

<?php
session_start();
//verification : affiche le tableau qui contient les variables de session
//print_r($_SESSION);
//verification envoi login et pass
if(isset($_POST) && !empty($_POST['login1']) && !empty($_POST['pass1'])){
//extraction de login et pass du tableau en tant que variables
extract($_POST);
$pass1 = sha1($pass1);
//CONNEXION selection BASE DONNEE
$db=mysql_connect("mabase.eu.mysql", "mabase_eu", ".........");
mysql_select_db("mabase_eu", $db);
// lancement requete
$sql = " SELECT id FROM matable WHERE login1='$login1' AND pass1='$pass1'";
$req = mysql_query($sql) or die(mysql_error());
//echo mysql_num_rows($req);// nombre de correspondance trouvée + condition si correspondance > 0
if(mysql_num_rows($req)>0){
$_SESSION['Authentification'] = array(
// creation champs tableau AUTH
'login1' => $login1,
'pass1' => $pass1
);
header('Location:pageprivee.php'); // à ce niveau je m'aperçois que même si je clique sur pageprivee2.php en session privee, je dois me reloguer à chaque fois et reviens toujours sur pageprivee1 - à voir peut être avec l'objet de mes difficultés en bas de page- ..
}
else{
echo "mauvais identifiant login1";
}
}
?>

qui contient aussi mon formulaire ci dessous

<form action="login.php" method="post">
<fieldset>
<legend>Merci de vous authentifier en session confidentielle</legend>
<p>
<label for="login1">Login :</label>
<input type="text" name="login1"/>
</p>
<p>
<label for="password">Password :</label>
<input type="password" name="pass1"/>
<input type="submit" value="Vous connecter"/>
</p>
</fieldset>
</form>

Puis mon fichier de déconnexion logout.php

<?php
session_start();
$_SESSION = array();
session_destroy();
header("Location: http://www.monSitePublic.eu");
?>

AUTHENTIFICATION
Fichier class Authentification.php

<?php
class Authentification{
static function isLogged(){
if(isset($_SESSION['Authentification']) && isset($_SESSION['Authentification']['login1']) && isset($_SESSION['Authentification']['pass1'])){
return true;
}
else{
return false;
}
}
}
?>

Enfin mes fichiers pageprivee1.php, pageprivee2.php,...

<?php
session_start();
require("authentification.php");
if(Authentification::isLogged()){

}
else{
header('Location: login.php');
}
?><!DOCTYPE html>
<html>
...
</html>

L'objet de mes difficultés :

Chaque pageprivee.php contient un menu de navigation d'une pageprivee à l'autre
Si je me logue via login.php, j'ouvre bien ma pageprivee1.php ... et lorsque je clique sur pageprivee2.php je dois de nouveau me reloguer malgré que je me sois déjà authentifié en me loguant sur pageprivee1.php via authentification.php.

A priori mes connexions en Bdn se font normalement.

Merci de l'aide,
pierrot

Jc · 17-09-2014 07:06:55

Bonjour,

Cette démarche t'honores pierrot.
Alors beaucoup de choses à dire sur ce code.

1ère règle à respecter : Ne jamais stocker un login et un mot de passe au niveau applicatif, et laisser ce travail à la DB. On s'assure de la confidentialité de la transmission de cette information à la BD pour vérification via SSL (entre le client et Apache/IIS).

Donc au lieu de stocker le login et le mot de passe en session, il est préférable de stocker l'ID, le Nom et le Prénom de la personne connectée pour le moins.

Ensuite pour les tests d'existence du login il faut également vérifier le contenu et le typage des valeurs en plus de leur existence, et pour le moins, à cause du fait que ces variables ne sont pas protégées par une classe avec getter/Login=>setter sur ces valeurs.

++

pierrot35 · 17-09-2014 12:51:06

Bonjour,

merci de "réatteler", ton aide me sera un atout important comme la dernière fois.

Concernant la 1ére règle
tu indiques de ne jamais stocker Login & Mdp au niveau applicatif, je pensais que si je stockais ceux-ci dans ma base et que j'allais vérifier leurs concordances avec le login & Mdp sha1 entrés dans le formulaire, il devenait difficile de les "pirater" ?

Si une des informations du formulaire est erronée après vérification en Bd, je retourne "mauvais identifiants", je croyais donc que le login et Mdp ne remontait pas au niveau applicatif ? qu'ils étaient simplement vérifiés par la requête ?

J'ai dans ma Bd, l'Id, login et mot de passe, le mot de passe étant entré déjà en crypté sha1 dans la Bd, c'est pour ça que j'ai crypté sa variable dans le login.php - $pass1=sha1($pass1);-
Lorsque je suis la vidéo tuto, je teste le passage des variables login/Mdp avec print_r($_SESSION), j'ai :
Array([Authentification]-=>Array([login1]=>[pass1]=> c1289acbc563258eafd2466....)), le mot de passe qui est passé est donc bien crypté sha1 et, si j'ai compris, il serait impossible de le décrypter " à l'envers" dans l'applicatif ?, je pensais être en sécurité puisque le Mdp de ma base est également en sha1...

Tu m'indiques devoir stocker l'Id, le nom et le prénom de la personne connectée.
La personne qui veut entrer sur la session privée rempli un formulaire en session publique, y note ses coordonnées, et après cela je lui envoie par mail les codes d'accès de la session privée.
Cela ferait que je dois entrer dans ma Bd les coordonnées de la personne ?

Tu vois, je suis toujours débutant..

Je vais travailler sur ce que tu m'indiques et améliorer la sécurité, je vais bien finir par y arriver.. avant de passer sur postgresql..plus tard...
Peux tu me dire mes erreurs de raisonnements, je vais y aller étape par étape, tranquillement.
merci bien
pierrot

Jc · 18-09-2014 17:11:45

sBonjour,

1) Quand je dis "au niveau applicatif" il s'agit de l'application objet = PHP et non de la base de données.
2) vérifier le login + mdp sur la db c'est bien ce qu'il faut faire, par contre il ne faut pas stocker l'information au niveau de la Session PHP ni au niveau d'un objet PHP persistant.
3) le SHA1 il faut l'appliquer au niveau de la requête et non pas de PHP
4) Quand on applique la fonction SHA1 à une chaîne de caractères, cela ne s'appelle pas "Crypter" mais "Hasher", car le cryptage est une opération réversible contrairement au hashage.
5) Ce qu'il faut stocker par exemple au niveau de PHP c'est $_SESSION['Authentification']=serialize(array("Id"=>2,"Nom"=>"DUPONT","Prénom"=>"Jean-Louis")); sur le retour de la requête de vérification du login + Mot de passe.
6) Oui cela oblige à connaître le nom et le prénom ou le prénom pour le moins de la personne qui se connecte. En général quand on passe en mode connecté, on est identifié donc connu et on est plus anonyme. Donc il est normal d'avoir ces informations.

++

Dernière modification par Jc (18-09-2014 17:13:33)

pierrot35 · 19-09-2014 12:38:21

Bonjour Jc,

je pense avoir compris un petit peu, je vais reprendre tes conseils point par point pour tenter de les mettre en application.

Ton retour 4 /Merci pour la différence entre crypter et hasher, je ne le savais pas, cela veut dire que le sha1 est irréversible, si je ne me trompe pas..

Ton retour 2 / Concernant le stockage en php, ou je dois alors le stocker ?
il est pourtant bien, me semble t'il, dans le tableau de session "Authentification" que j'ai par ailleurs modifié hier (tuto) , cela donne maintenant (et ça fonctionne sans erreur) :
<?php
class Authentification{
static function isLogged(){
if(isset($_SESSION['Authentification']) && isset($_SESSION['Authentification']['login1']) && isset($_SESSION['Authentification']['pass1'])){
extract($_SESSION['Authentification']);
$db=mysql_connect("mabase.eu.mysql", "mabase_eu", "mon code accés Bd");
mysql_select_db("mabase.eu", $db);
$sql = " SELECT id FROM confid WHERE login1='$login1' AND pass1='$pass1'";
$req = mysql_query($sql) or die(mysql_error());
if(mysql_num_rows($req)>0){
return true;
}
else{
return false;
}
}
else{
return false;
}
}
}
?>

Ton retour 6 /Cependant,juste une interrogation, comme tu le précises cela oblige à connaître les noms, prénoms,.. de la personne, et donc je dois les enregistrer préalablement dans la Bd, et pour les enregistrer il faut que lors du remplissage du formulaire public je capte leurs coordonnées, c'est ça ? et que donc je dois aussi sécuriser le formulaire public ?
Donc si je résume le processus :
MonSitePublic =>FormulairePublic=>enregistrement informations de contact du Formulaire Public dans la Bd=>envoi Login&Mdp privé au contact => login du contact en Session privée en cohérence avec la Bd=> utilisation du 2nd formulaire privé pour échange confidentiel en session privée.
Je devrai probablement aussi sécuriser le formulaire public puisqu'il échange avec la Bd ?

J'avais déjà abordé l'enregistrement en Bd à partir des infos du formulaire privé, donc après login privé, mais j'avais arrêté puisque j'avais déjà du mal avec la "simple" sécurisation.
Voilà ce que j'avais fait dans le code du formulaire de la session privée, mais cela ne fonctionnait pas..:
<?php
session_start();
require("authentification.php");
if(Authentification::isLogged()){
$db=mysql_connect("opuscloud.eu.mysql", "opuscloud_eu", "y0vkxg@44");
mysql_select_db("opuscloud_eu", $db);
$query= mysql_query("INSERT INTO confid VALUES(",'$nomprenom','$mail','$telephone'")");
}
else{
header('Location: login.php');
}

.. erreur ligne 7 ..

Pour synthétiser
1/ Je vais tout reposer pour ne pas entrer dans une complexité immédiate que je ne saurai maîtriser, donc l'ordre de travail serait en priorité d'enregistrer les infos contact du formulaire public dans ma Bd avnat toute autre chose.
2/ puis ensuite travailler sur cela ( $_SESSION['Authentification']=serialize(array("Id"=>2,"Nom"=>"DUPONT","Prénom"=>"Jean-Louis")); sur le retour de la requête de vérification du login + Mot de passe.

je vais aller dans ce sens.
Pour info, J'ai trouvé mon erreur, maintenant tout fonctionne,la session privée est accessible uniquement par le login et je peux passer de page privée en page privée tant que je n'ai pas actionné le logout.

Merci encore pour ta guidance, j'avance là ou je ne pensais pas être en capacité d'aller..
pierrot

Dernière modification par pierrot35 (19-09-2014 12:43:41)

Jc · 20-09-2014 09:42:31

Bonjour,

Niveau processus ce n'est pas cela.
1) D'abord, il faut savoir que tout ce qui transite en clair via le réseau reste dans le domaine public: n'importe qui peut lire ces informations sur le réseau si elles ne sont pas cryptées en SSL (connexion https). Dit encore différemment, si vous n'êtes pas en https, les informations fournies ne peuvent être considérées comme confidentielles/privées). Donc tout formulaire de saisie utilisateur doit être fourni en mode https si l'on se soucie à minima de ses clients/utilisateurs.
2) Par extension il en va de même avec les mails. Donc on n'envoie aucun mot de passe à l'utilisateur par mail. Il y a beaucoup trop de sites "pro" qui le font, par incompétence caractérisée de leur webmaster / prestataire technique de gestion de site.)

La suite plus tard, je dois m'absenter.

pierrot35 · 20-09-2014 15:34:05

Bonjour Jc,
Je crois que tu as raison, les informations du formulaire public doivent être également protégées.
J'ai mis tout les site en https, maintenant avec .htaccess je vais essayer de rewriter les fichiers (autres que le fichier formulaire) de https vers http,
Normalement le fichier formulaire resterait en https et les autres en http, je vais essayer
Ça doit ressembler à qqchose comme ça dans un fichier .htacces placé dans le répertoire du dossier formulaire:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Bon Week End
et merci bien sûr
PIERROT

pierrot35 · 21-09-2014 11:11:01

Ça y est, mon formulaire public est https://xxxxx.eu/demande%20informations.php, les autres IHM restent en http://...

Jc · 21-09-2014 11:20:08

Bonjour,

Normalement le fichier formulaire resterait en https et les autres en http, je vais essayer

Oui tout à fait. Il faut également éviter de mettre sur une page d'accueil un module de connexion par exemple et privilégier une page spécifique en https pour ce faire. Cela évite de mettre la page d'accueil en https et permet d'accroître la capacité de monté en charge de ton site. (Rapport de 1/1000 pour la capacité de gestion de connexions simultanées entre les deux). Du coup cela simplifie et allège la gestion du rewrite sur ton serveur. le mieux est de mettre l'application en mode connecté en sous-domaine : ex: https://backoffice.mondomaine.fr . De plus le jour où tu as besoin de segmenter tes ressources, tu peux facilement mettre le sous domaine sur un autre serveur (par ex. dédié à la gestion des connexions https).
et sur ce sous domaine pour forcer le https, le rewrite c'est plutôt du style:

            RewriteEngine on

            RewriteCond %{SERVER_PORT} 80

            RewriteCond %{HTTP_HOST} ^backoffice.mondomaine.fr$

            RewriteRule ^(.*)$ https://backoffice.mondomaine.fr/$1 [QSA,R]

De plus si tu peux passer ton serveur en https, c'est que normalement tu as un accès SSH au système, donc tu peux accéder au fichier de configuration d'apache. Je te conseille alors d'y mettre tes règles de rewrite directement plutôt que dans ton .htaccess . La raison est encore très simple : les règles du .htaccess sont réévaluées à chaque requête serveur, alors que dans le fichier de configuration, elles ne sont évaluées qu'une fois : lors du chargement d'apache. Donc beaucoup plus de performances à la clef.

Pour la gestion de connexion tu es loin du compte je te conseille de faire un truc du genre :

class my_connection {

  private $u_id=0;

  private $u_lastname='';

  private $u_firstnames='';

  private $u_connected=false;

 private function initialization(){ 

     this->u_id=0; $this->u_lastname=''; $this->u_firstnames=''; $this->u_connected=false;

 }

  public function login($login,$pwd){

      // ce n'est qu'un exemple, je reprends ta méthode pour la gestion de la persistance.

      // 1) vérification type et format $login et $pwd

      // si pas ok  : $this->initialization(); return false;

      //  $sql = " SELECT id,lastname,firstnames FROM confid WHERE login1='$login1' AND pass1=SHA1('$pass1')";

      // si enregistrement pas retourné ou si id=0 => $this->initialization(); return false;

     // $this->u_id=intval($resultset['id']); $this->u_lastname=$resultset['lastname']; $this->u_firstnames=$resultset['firstnames'];

     // $this->u_connected=true;

     return true;

  }

  public function is_connected()    { return $this->u_connected;}

  public function user_name()       { return $this->u_lastname;}

  public function user_firstnames(){ return $this->u_firstnames;}

}

L'idée est là. Reste à sérialiser la classe en session pour gérer la persistance de connection, et mettre à jour la sérialisation en cas de modification de statut de connection.
Pour ce faire je te recommande de faire de cette classe un singleton.

voilà bon dimanche

Edit : pour sécuriser et forcer le https sur un simple formulaire, je te recommande de tester le port de connexion directement dans l'entête de la page. Si le port est 80 alors tu fais une redirection immédiate par meta sur l'adresse de la page en mode sécurisé.

Dernière modification par Jc (22-09-2014 06:59:25)

Jc · 22-09-2014 07:06:42

Bonjour,

Tu t'en sors? S'il y a des choses que tu ne comprends pas fais-moi signe. Mon post précédent n'est pas la solution mais le point de départ pour la mettre en place pour que les choses soient faites correctement en php. Donc il y a un certain nombre de choses à rajouter dans le code fourni pour qu'il soit fonctionnel.

Bonne journée.

Dernière modification par Jc (22-09-2014 07:07:03)

pierrot35 · 22-09-2014 18:48:14

Bonsoir Jc,
Je te remercie d'avoir pris un peu te ton temps.

je viens de passer la journée à vouloir passer des infos du formulaire dans ma base, en vain.. je dois faire encore une erreur que je trouverais ..demain..

J'ai lu avec une grande attention tes posts, je dois t'avouer que pour petit niveau ça me semble très compliqué, je suis parti, comme tu le disais, d'un minimum syndical...mais ça progresse quand même pas mal.

Effectivement, chez l'hébergeur du site j'ai fini par activer le SSL après avoir tenté de passer par les htacess ( ça marchait pas), en fait il suffisait simplement, après activation SSL (environ 2h d'attente pour que ce soit actif), de gérer les liens en http ou https, j'ai donc positionnés mes liens https uniquement vers les 2 formulaires, les autres IHM restent en http.
Comme tu me l'indiques mes pages d'accueils publiques et privées restent donc en http simple.

Concernant mon application, je l'héberge sur un serveur à mon domicile ( appli java en SAAS+postgresql ( mysql pas assez puissant), je bosse avec l'IDE Netbeans sous linux/Ubuntu serveur), je pensais ultérieurement faire un lien du site vers mon serveur via NoIp ( je suis en Ip dynamique). J'essaie de simplifier et ne pas mettre "tout mes oeufs dans le même panier" en sécurisant chaque entité site et appli individuellement, cela me semble moins compliqué, moins risqué et moins cher.
Comme tu l'as indiqué, il est vrai que je vais devoir aussi associer le site et mon serveur, chacun en https, mais ça va vite pour moi, je suis toujours qu'un hyper débutant..

Sur htacess,Je pense avoir à peu prés compris ton explication sur htacess et la réévaluation des requêtes, je vais en tenir compte dés que j'aurai franchi l'étape d'enregistrement du formulaire dans ma bd, le https étant, j'espére ok maintenant ( sauf vérification du port 80).

Les codes de connexions que tu m'as notés, je les ai copiés mais je crains d'aller "un peu, un pont trop loin, trop vite", je vais être de toute façon obligé de les retravailler dans ton sens, puisque je vais devoir ajouter ultérieurement des rôles de connexions suivant le statut de chaque connecté.

J'ai pas compris ta redirection meta ? je devrai me rediriger vers une adresse en https alors que mon accueil est en http ?

Merci encore de ton aide, sincèrement je ne pensais pas déjà arriver là.
pierrot

Jc · 23-09-2014 09:03:41

Bonjour,

je viens de te lire avec attention, et je te recommande vivement de faire attention à ceci:
- Bien que je ne connaisse pas les conditions d'exploitation de ton appli, vu qu'elle est censée être distribuée en SAAS, il est bien plus cher de vouloir assuré ce service on-premise (sur site) qu'en ligne. Je te conseille vivement de passer ton appli en ligne assez rapidement sur un serveur disposant d'une SLA que tu puisses répercuter sur tes clients. Un des premiers critères sur un mode SAAS est la disponibilité, et tu ne pourras la garantir en mode on-premise, et je doute que ton assureur te suive dans cette voie.
- En ce qui concerne postgreSQL vs MySQL, on est bien d'accord. Je te conseille de faire tourner ton site sur du postgreSQL également afin de pouvoir faire tourner ton site et ton appli sur une base unifiée à terme.

Maintenant en ce qui concerne la sécurisation d'une page ex : https://www.mondomaine.fr/contact.html alors que le reste des pages sont en http, le meilleur moyen est de le faire en PHP et non pas via rewrite. ex:

<?php If (intval($_SERVER['SERVER_PORT'])===80)){header('Location: https://www.mondomaine.fr/contact.html');exit;} ?>

 

Ceci afin qu'un internaute n'utilise pas la page en mode non sécurisé par inadvertance.

++

pierrot35 · 23-09-2014 10:35:47

Bonjour Jc,

En fait, l'appli est déjà en ligne et la connexion se fait directement sur le serveur via glassfish sur un port sécurisé + identifiant et Mdp, ce que je voudrais est de permettre aux visiteurs de visiter une version demo de l'appli en évitant de leurs communiquer l'url https d’accès direct.
J'ai accès direct à mon serveur alors que j'étais précédemment chez Ovh sur un serveur mutualisé, mais cela me posait qq difficultés de maintenance en ligne et de puissance Ram , maintenant que j'ai réinstallé l'appli je peux directement travailler sur ubuntu.

Concernant le SLA ( je ne savais pas ce que cela voulait dire), c'est, si j'ai compris, un cahier des charges que chacun doit respecter, du genre du document que l'on doit accepter pour installer un logiciel en ligne. Je n'ai pas mis en ligne ce type de document, c'est un peu plus compliqué que cela puisque je souhaite distribuer cette appli en marque blanche, mais je ne peux entrer toutes les infos sur un forum public, si tu le souhaitais, il doit être possible de t'envoyer ces infos en conversation privée via le forum pour que tu puisses viser par ton expertise.
Pour info
Projeter une distribution en marque blanche fait que chaque "distributeur" travaillera avec une seule et unique base postgresql ( la mienne), tout en travaillant sur des applications indépendantes sous leurs propres marques mais sur le même serveur ( redirection domaine/port en fonction de chaque marque)
Chaque marque blanche utilisera alors la même bd postrgresql, Il y a donc un complexe de sécurisation à créer au fur et à mesure du déploiement commercial de chaque marque d'appli et de ses clients utilisateurs..

Les sites commerciaux des distributeurs en marque blanche restent des éléments de commercialisation de l'appli sous leurs propres marques sans lien url avec mon site ou l'appli
Le site que je finis est, entr'autres*, un outil de commercialisation de cette marque blanche qui doit bien sécurisé puisque la formalisation des échanges avec les distributeurs transiteront par là.
Mysql me semblait suffisant pour ces échanges commerciaux, et puis mon hébergeur ne propose pas postgresql mais que mysql, il n'y aura à priori pas de liens entre postgresl/appli et mysql/site.

La sécurisation des 2 formulaires ( un en session publique et l'autre en session privée) est maintenant opérationnelles en https://.., mais je n'ai pas eu à utiliser un codage htacess ayant activé le SSL de mon hébergeur (donc pas de rewrite de ma part malgré ce que j’avais commencé à faire).
Par contre,je ne sais pas quel port est utilisé ? faut il que j'ajoute ta ligne de code en plus ? il y a qqchose qui m'échappe encore, je pensais que cela aurait été compliqué de mettre les formulaires en https via htacess, mais en fait ça c'est fait automatiquement et de ce fait je n'ai pas appris grand chose sur ce théme.

C'est en fait très très compliqué pour moi, j'ai à apprendre sur le tas, maintenant je touche un peu à tout sans être, et loin s'en faut, un quelconque expert informatique, dés que je tombe sur qqcghose de compliqué, eh bien... ça se complique vraiment.. et passe parfois des jours sur un problème qui demande qq heures.. et c'est pas aussi fréquent d'avoir de l'aide sur certains forums sans passer pour un trublion sans niveau, entre experts, excuses moi, c'était mon quart d'heure philosophie..

Je vais retourner sur mes entrées de données formulaires en bd en attendant tes observations, crois bien en la sincérité de mes remerciements, c'est rare...
J’espère que je ne suis pas trop bavard, mais il me semblait, au vu de tes post, qu'il fallait que tu ai un aperçu plus élargi de mes difficultés, si je suis confus n'hésite pas à me le dire.
Auquel cas je n'arrive pas à entrer mes données de formulaires aujourd'hui, je te contacte.
en attendant tes retours
merci encore
pierrot

Jc · 23-09-2014 17:54:41

Bonjour,

- Concernant la SLA ce n'est pas cela du tout. SLA="Service Level Agreement" qui est une convention contractuelle de garantie de niveau de service, notamment de disponibilité.
Par exemple pour une SLA de 99,99% : http://uptime.is/advanced?sla=99.99&dur … =24&dur=24

- Ensuite la solution pour éviter le mutualisé classique chez OVH est de passer par du VPS Cloud qui intègre une SLA de 99,99%, ce que vous ne pourrez jamais garantir en l'état actuel de votre infrastructure.
C'est ce que j'utilise pour mes applis en SAAS, en attendant de passer sur du dedicated Cloud.

- Je ne pense pas non plus que la stratégie que vous ayez adoptée (une application physique par marque blanche) soit techniquement judicieuse. Elle va vous coûter chère en maintenance et en hébergement pour maintenir la qualité de service. Vous risquez de ne plus être rentable à terme, avec l'accroissement du nombre de vos clients en marque blanche.

- Il y a d'autres techniques pour arriver à vos fins avec une seule application et en restant cloisonné au niveau données.

- Le SSL ne passe aucunement par le .htaccess (cela n'a rien à voir).

Bonne soirée

EDIT: Le VPS permmet d'accéder au système en tant que root, vous pouvez donc installer postgreSQL et le configurer à votre convenance. Je te conseille aussi pour du SAAS de passer par du CentOS que par du Ubuntu moins stable niveau mises à jour.

Dernière modification par Jc (24-09-2014 12:11:17)

pierrot35 · 24-09-2014 12:11:58

Bonjour,

- le SLA="Service Level Agreement"
Cette fois je pense peut être (?) avoir compris, à priori cette garantie de niveau de service s'adosse essentiellement à la disponibilité du serveur ? mais alors la qualité de l'appli et des services qui lui sont associés n'entrent pas dans ce concept ? Si c'était le cas, le problème serait uniquement le choix d'une typologie de serveur ? c'est à peu prés ça ?

- Sur le vps cloud
s'agit 'il de serveur dédié ? quelle différence y a t'il entre le Vps cloud et le mutualisé classique, il semble que le Vps cloud est un "dédié" sur un serveur physique partagé ? et que dans les 2 cas les ressources du serveur soient partagées ?
Je n'ai de toutes façon pas les moyens d'accéder, pour l'instant, à ces types d'hébergements. J'ai essayé il y a qq mois, mais je n'ai eu que des problèmes alors j'ai monté mon propre serveur. Dans un 1er temps, quoique tu ais totalement raison, je vais me contenter de ce que j'ai puis après, suivant l'évolution du dispositif, j'évoluerai vers une structuration plus pertinente.

- sur l'application physique par marque blanche
L'appli doit être reconfigurée suivant les chartes graphiques des distributeurs, et pourrait aussi être revue, mais modérément, sur son contenu.
Je ne sais pas encore si le coût l'hébergement et maintenance de chaque appli sera à ma charge ou à la charge du distributeur , cela reste ouvert selon le rythme de déroulement du projet. Actuellement je dois rester simple et monter en capacité de structuration au fur et à mesure des implantations, je sais que c'est faire les choses à l'envers, mais je n'ai ni la compétence ni les moyens financiers pour mettre en place un idéal, tout ce que je peux faire est me préparer à cela sans par ailleurs savoir comment. Si je me pose trop de questions sans que je sais pertinemment sans réponses ou sans moyen de les mettre en œuvre, je ne vais plus pouvoir avancer, mais je t'ai bien compris et suis totalement en accord avec toi, mais je n'ai les moyens de me payer une ferrai, alors ( pour l'instant) ma 2 chevaux me suffit, c'est un choix par défaut, après .. on verra

- les autres techniques de cloisonnement de données
Pourrais tu me dire qq mots la dessus, pour ma part je me disais qu'avec glassfish je pouvais rediriger chaque distributeur/utilisateur sur un port de déploiement de telle ou telle appli selon l'appli qui lui est destiné, sans toucher à ma base.

- sur le SSL, Alors je n'ai pas compris, pourquoi j'ai du activer le SSL pour pouvoir procéder aux liens https des formulaires sinon cela ne fonctionnait pas ? mais pour revenir à ma "simple" préoccupation, le fait que l’accès privé soit hasher avec Login et mot de passe, que mon formulaire principal soit positionné derrière et "formater" en https, cela protège t'il correctement les informations qui y circulent ?

En résumé, il faut que je sois réaliste, je suis incapable actuellement d'atteindre le niveau d'un pro, j'ai rêvé, il faut que je remette les pieds sur terre tout en prenant en compte, suivant mes possibilités, les évolutions critiques, en tout ou partie, dont tu me fais part. Cela à déjà fait exploser "le minimum syndical" de départ, mais plus je veux "être parfait" plus je m'aperçois que j'en suis incapable actuellement. Néanmoins, je ne me doutais pas du tout de l'ensemble de la complexité que tu m'as fait apercevoir et ne pourrai pas y échapper, mais doucement,.. plus j'en sais et moins je sais pouvoir savoir .. mais si le projet décolle, j'externaliserai et je ferai appel à ton expertise dans un contexte de partenariat en sous-traitance, si cela te convenait en ce temps. Je pense que le projet, dont je ne peux tout dévoiler ici, comporte encore bien d'autres aspects qui nécessiteront du travail d’orfèvre hors de ma portée.

Pour revenir sur "MA terre", avant de repartir sur tes conseils, je n'arrive toujours pas à enregistrer mes données de formulaire dans ma bd, l'enregistrement se fait en bd mais le(s) contenu(s) du formulaires n'apparaissent pas dans ma table . Je teste avec une seule donnée, après j'intégrerai les autres
peux tu m'indiquer ou je faute ?

Mon formulaire
<div class="cfg-element-container">
<label class="cfg-label" id="cfg-element-35-7-label" ><span class="cfg-label-value">Nom Prénom</span><span class="cfg-required">*</span></label>
<div class="cfg-element-set" id="cfg-element-35-7-set" >
<div class="cfg-element-content">

<input type="text" class="cfg-type-text cfg-form-value " name="nomtobd" id="cfg-element-35-7" />
<?php
if(isset($_POST['nomtobd'])) $nomtobd=$_POST['nomtobd'];//recup champs <input type="text" name="nomtobd" />
else $nomtobd="";
$db=mysql_connect("mabase.eu.mysql", "mabase_eu", "**********");//connexion base
mysql_select_db("mabase_eu.mysql", $db);//selection bd
$sql = "INSERT INTO matable(id, nomprenom) VALUES('','$nomtobd')";// requête sql
mysql_query($sql) or die('Erreur SQL !'.$sql.'<br>'.mysql_error());// insertion table
mysql_close();//fermeture base
?>
</div>
</div>
<div class="cfg-clear"></div>
</div>

Je ne sais plus si je dois de tutoyer , excuse cette question
merci beaucoup
pierrot

Dernière modification par pierrot35 (24-09-2014 13:02:50)

Jc · 24-09-2014 12:50:18

Bonjour

- En ce qui concerne la SLA, pour pouvoir l'assurer il faut prévoir et anticiper les défaillances matérielles (carte réseau qui tombe, disque dur qui rends l'âme, etc...) plus éventuellement les astreintes pour intervenir physiquement sur la machine lorsque cela est nécessaire en 24/24h et 7/7j. Donc cela passe par de la redondance matérielle et des couplages de système RAID au niveau disque. Donc difficile à assurer on-premise à son bureau..

- Pour le VPS (Virtual Private Server) qui est donc un serveur privé virtuel, les avantages sont nombreux. On est en effet en mutualisé sur une machine et même plusieurs, mais "on ne partage pas" les ressources qui nous sont attribuées. On accède en root à la machine, sur l'OS de notre choix, bref c'est du dédié au niveau technique et nécessite les compétences qui vont avec pour l'administrer. L'avantage aussi, chez OVH avec le VPS c'est que l'on dispose d'une adresse IP dédiée par VPS qui peut être étendue à 4 sur du VPS Cloud. L'avantage, c'est que l'on maîtrise la réputation de son adresse IP, vu que l'on ne la partage pas. En mutualisé chez OVH on peut être environ 1million de sites à partager la même IP.... Autre avantage également, c'est que si l'on devient juste en ressources en étant par exemple en VPS 2, on peut passer en VPS 3 à chaud en moins de 5min, sans pour autant devoir migrer de serveur, ce qui offre une souplesse de gestion non négligeable.
En plus l'installation d'un certificat SSL sur un serveur nécessite l'utilisation d'une adresse IP fixe à la base. Je sais que cela n'est pas ton cas, et cela oblige donc à une grosse complication technique pour contourner cette exigence. CloudFlare aux USA, fonctionnent avec une telle complexification sur leur réseau mondial.
Peut être que du VPS classic chez ovh peut te suffire...

- Quand tu vends en SAAS, c'est à toi d'inclure le coût d'hébergement dans ton abonnement + le coût de location de l'application. Sauf à être en mode "SAAS privé" qui est un peu à part. En sachant que ce coût est mutualisé. A toi donc de baisser le prix de revient d'exploitation pour être et rester concurrentiel. Une question que tu peux te poser, c'est en combien de temps une nouvelle souscription est opérationnelle en marque blanche pour ta solution? Combien tu peux en mettre en place par jour? Ensuite tu pondères cela avec le nombre de clients qu'il te faut pour atteindre ton seuil de rentabilité... et tu vois si cela reste techniquement gérable sans devoir embaucher pour pouvoir suivre, auquel cas, ton prix de revient augmente.
Ton choix de passer par une appli java en mode web, complexifie également techniquement tout ça, et contribue à augmenter tes coûts d'exploitation.

- Concernant le cloisonnement des données, tu souhaites apparemment mettre en place une connexion distincte par application à une base de données commune. Ceci va te consommer énormément de ressources sur ton SGBDR pour rien. Je peux argumenter ici, mais cela serait long à expliquer.

- Le SSL passe par le protocole TLS qui sert à sécuriser une connexion distante réseau. Le SSL crypte en plus les données qui y transitent. Sans rentrer dans les détails de la non-répudiation, intégrité et confidentialité des données, cela ne concerne donc que les communications réseau. Le Hashage du mot de passe n'est opéré qu'en bout de chaîne pour stocker le mot de passe dans la base de données, pour éviter par exemple qu'un employé indélicat qui à accès à la base de données puisse connaître le mot de passe d'un client et établir une connection sur le serveur en se faisant passer pour ce client une fois rentré chez lui.

Pour le reste ne t'inquiète pas, c'est le métier qui rentre

++

Dernière modification par Jc (24-09-2014 13:58:36)

PHP|Débutant :: Forums

Advertisement

#1 16-08-2014 11:12:18