Discussion :

[redah75]

Et bien tu vois qu'en insistant un peu on parvient à trouver le truc.

merci

...
Pourquoi donc ne pas le mettre aussi en paramètre ?
...

$sxml est ce qui me permet d'afficher les textes traduits car g tous mes textes de traduction au format xml et que j'exploite avec la fonction $sxml = simplexml_load_file(); puis echo $sxml->nom_balise;
j'ai au fait decidé de declaré $sxml en global a l'interieur de la fonction pour garder une certaines homogeneite niveau code car j'ai parfois plusieurs variables a utiliser dans les fonction et afin d'eviter d'avoir trop de parametres:
nom_fonction(var1, var2, var3, var4, ...);
est ce que ca pose probleme coté securité d'avoir des variables globals dans une fonction??

D'ailleurs, pour formater des prix Français/Anglais, tu pourrais adopter le même principe, car la position des symboles (€/$) cause à peu près le même problème.
La solution est simple, et efficace.

apres avoir bien compris l'importance de sprintf, j'ai vraiment pensé a l'utiliser pour formater les prix mais je n'y suis pas parvenu. comment pourrais je faire pour avoir un chiffre sur le site anglais sous cette forme: 1,320.50 ou 10,320.50 et 1 320,50 pour le site francais??
en combinaison avec number_format()??

[RunCodePhp]

j'ai au fait decidé de declaré $sxml en global a l'interieur de la fonction pour garder une certaines homogeneite niveau code car j'ai parfois plusieurs variables a utiliser dans les fonction et afin d'eviter d'avoir trop de parametres:
nom_fonction(var1, var2, var3, var4, ...);

Je ne vois de quel homogénéité et de fonction dont tu parle.
Je vois une fonction show_date() qui attend actuellement 2 paramètres indispensables $format et $dt, et $sxml me semble tout aussi indispensable.
Le rajouter dans cette fonction revient au même au niveau fonctionnalité, à part quel ne sera globale.
Enfin, c'est moyen je l'admets vu que le Objets passent par référence depuis Php5.

est ce que ca pose probleme coté securité d'avoir des variables globals dans une fonction??

Il ne faut pas toujours tout ramener à la sécurité.

Je ne sais plus si c'est avec toi que j'en avais parlé, mais le souci de mettre une flopée de variables déclarées en globales dans les fonctions c'est que ça provoque un énorme manque de maitrise sur ces variables, du coup ça demande de très bien connaitre son code, et tout le temps.
Le facteur temps joue très nettement en défaveur d'ailleurs.

Ne pas perdre de vu que mettre en global une variable dans une fonction fait que celle ci est la même référence que celle qui ce trouve en-dehors de la fonction.
Si on effectue une modification sur celle ci (par erreur ou volontairement) ça aura un impacte sur celle qui est en-dehors.
Si par malheurs il y a un bug, ça peu devenir un sacré gros problème, un vrai jeu de piste pour ne serait-ce trouver l'origine du bug.

Si tu passe une variable dans la fonction, cette variable n'aura qu'une portée locale, donc quoi qu'il se passe dans la fonction, ça n'aura aucun impacte sur cette variable en-dehors, ce n'est franchement pas la même chose.
Les 2 exceptions sont :
- Si la donnée est un Objet
- Si on rajoute explicitement le passage par référence (ex. function ma_fonction(&$var_par_reference, $var_par_valeur)

En conclusion.
Tu effectue un choix en grande partie pour ton propre confort, (éviter d'avoir trop de paramètres dans des fonctions), donc pas pour des raisons purement technique.

Bon, si ça peu te rassurer, les déclarations globales dans les fonctions je l'ai fait et abuser très largement, et il n'y a pas si longtemps.
Mais je t'assure qu'avec le temps on révise très largement ce choix à cause de ce manque de visibilité du code que ça provoque.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

comment pourrais je faire pour avoir un chiffre sur le site anglais sous cette forme: 1,320.50 ou 10,320.50 et 1 320,50 pour le site francais??

La fonction number_format() attend 4 paramètres :
- float $number
- int $decimals
- string $dec_point
- string $thousands_sep
A mon sens, et comme cela est lié aux langues, il faudrait que ces 3 derniers paramètres (particulièrement les 2 derniers) viennent des config au niveau des langue (ton xml ou autre constantes).
Si c'est l'anglais :
$dec_point vaudra . (point), $thousands_sep vaudra , (virgule)
pour le Français :
$dec_point vaudra , (virgule), $thousands_sep vaudra _ (espace)

Après, il faudrait peut être encore 2 autre configs, comme symbole_gauche, symbole_droit pour pouvoir tantôt le placer à gauche ou à droite selon le cas, donc selon la langue, l'un vaudra vide et l'autre le symbole.


Bon, je te laisse lamentablement trouver le truc, ou mieux, t'a propre façon de faire

[redah75]

Je ne vois de quel homogénéité et de fonction dont tu parle.
Je vois une fonction show_date() qui attend actuellement 2 paramètres indispensables $format et $dt, et $sxml me semble tout aussi indispensable.
...

au fait j'ai une 15ene ou 20ene de fonctions pour l'instant, et toutes utilisent au moins 3 variables, et effectivement comme tu dis, pour une raison de confort, je les declare en global a l'interieur de la fonction. je modifierai tant qu'il est encore temps et pas trop tard

la langue (fr) et le pays (France) par exemple, ne serait il pas interessant de les declarer comme CONTANTE (define()) afin de s'en servir dans les fonctions sans devoir les passer en parametre??

d'autre part, je suis par fois obligé de declarer des variables en global car elles sont créées dans la fonction, et exploité en dehors de la fonction. ou as tu une autre facon de faire?

je vais voir ce que je peux faire pour le formatage des prix et je posterai la solution. ca peut toujours interessé quelqu'un

j'aimerais te demander ton avis et conseil sur un petit point stp.
maintenant que j'ai pris gout des sprintf et que je les apprecies bien, je compte changer mes textes de traduction en remplacant par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
$txt = "Bonjour monsieur {prenom} {nom},
suite a votre demande du {date} à {heure}..."
$search = array("{prenom}", "{nom}", ...);
$replace = array($prenom, $nom, ...);
echo str_replace($search, $replace, $txt);

par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$txt = "Bonjour monsieur %1$s %2$s,
suite a votre demande du %3$s à %4$s..."
printf($txt, $nom, $prenom, ...);

y a pas photo, la methode du printf est vachement mieux. mais plus tard quand je veux faire traduire mon fichier texte, le traducteur, risque de ne rien comprendre avec les %1$s et autres.... contrairement aux {nom}, {date}, ... quel choix ou sacrifice ferais tu???

[RunCodePhp]

... contrairement aux {nom}, {date}, ... quel choix ou sacrifice ferais tu???

Je ne vois pas trop le rapport, car les %1$s ou autre %s ne sont de toute manière pas à traduire, personne n'a à les toucher, ce sont des éléments dynamiques, au même titre que {prenom} ou {nom}.
Faut peut être briefer les traducteurs sur ce point.
Ceci dit, les %s ne sont pas très intuitifs, et ça peu rendre une traduction compliqué voir impossible, c'est vrai.

Petite parenthèse. Ce n'est pas tout le temps où la position des mots soient différents d'une langue à l'autre, donc les %1$s ne se justifient pas tout le temps, de simple %s %d peuvent suffirent et plus simple.


Et bien il faut peut être éviter de trop généraliser cette manière de faire (sprintf).
Ou alors mettre des commentaires pour donner un exemple de que chaque élément dynamique aurait comme valeur, j'en sait rien.

C'est quasi le même problème qu'il y a dans les systèmes de template, il y a des parties dynamiques, des boucles, des conditions, etc ... et les non-codeurs doivent apprendre à les repérer, et imaginer ce qu'ils doivent générer.
Il a guère le choix dans ce domaine à mon sens.

la langue (fr) et le pays (France) par exemple, ne serait il pas interessant de les declarer comme CONTANTE (define()) afin de s'en servir dans les fonctions sans devoir les passer en parametre??

Ne sont elle pas dans une session qui est un tableau super global, donc accessible aussi n'importe où ?

[redah75]

Je ne vois pas trop le rapport, car les %1$s ou autre %s ne sont de toute manière pas à traduire, personne n'a à les toucher, ce sont des éléments dynamiques, au même titre que {prenom} ou {nom}.

oui je sais, les %s ne sont pas a traduire, mais comme tu l'as dit apres, ca ne serait pas trop evident pour le traducteur de traduire un texte avec les %s au risque de ne rien comprendre. mais apres tout, je pense que si le traducteur voit un texte du genre: "Bonjour %s, je vous confirme votre commande qui date du %s ..." il comprendra bien qu'il s'agit du nom et de la date!!

Petite parenthèse. Ce n'est pas tout le temps où la position des mots soient différents d'une langue à l'autre, donc les %1$s ne se justifient pas tout le temps, de simple %s %d peuvent suffirent et plus simple.

t'as bien raison, ca ne doit pas etre crucial de preciser la position des variables...

Ne sont elle pas dans une session qui est un tableau super global, donc accessible aussi n'importe où ?

non!
j'ai un fichier nommé "langue-devise.php" appelé dans toutes les pages qui permet de recuperer quelques variables:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
$current_tld = ".co.uk";
$current_lang_iso_full = "en-gb";
$current_lang_iso = "en";
$current_lang = "English (UK)";
$current_country_iso = "GB";
$current_country = "United Kingdom";
$current_currency_symbol = "£";
$current_currency_code = "GBP";

devrais je les mettre dans une variable de session??
je precise juste que $current_currency_symbol et $current_currency_code peuvent changer a tout moment car l'utilisateur a la possibilité de changer la devise...

[redah75]

me revoila avec une solution pour la gestion de la devise, que j'espere est bien faite

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
$USD_decimal = ".";
$USD_thousands = ",";
$USD_symbol = "$";
$USD_format = '%2$s%1$s';
 
$GBP_decimal = ".";
$GBP_thousands = ",";
$GBP_symbol = "£";
$GBP_format = '%2$s%1$s';
 
$EUR_decimal = ",";
$EUR_thousands = " ";
$EUR_symbol = "€";
$EUR_format = '%1$s %2$s';
 
function show_amount($number, $decimal, $thousands, $symbol, $format) {
	$num = number_format($number, 2, $decimal, $thousands);
 
	return sprintf($format, $num, $symbol);
}
 
// $current_currency_code est generé depuis un autre script et retourne EUR, GRP ou USD
echo show_amount(1320.40, ${$current_currency_code.'_decimal'}, ${$current_currency_code.'_thousands'}, ${$current_currency_code.'_symbol'}, ${$current_currency_code.'_format'});

ma question est la suivante:
est il mieux de transmettre individuellement les 4 parametres par reference ou plutot avec une seule variable tableau dont la valeur sera:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$format_USD = array("decimal" => ".", "thousands" => ",", "symbol" => "$", "format" => '%2$s%1$s');

[RunCodePhp]

devrais je les mettre dans une variable de session??

Il y a l'air d'en avoir pas mal, entre les langues et les devises.
Dans des constantes ce n'est pas mal c'est vrai.
Mais c'est difficile de conseiller par moment vu que je ne suis pas confronté au problème, ça demande une vue d'ensemble au projet tout de même.
Je doute que ça s'arrête à l'usage d'une seule fonction par exemple.

Je vais le répéter je sais, mais c'est vraiment dommage que la POO ne soit pas encore connu de ton coté, car c'est ainsi que je ferais, donc ça n'aurait été ni dans la session ni dans des constantes, mais dans des Objets.
Ce genre de projet s'y prête pourtant à la POO, limite indispensable.

est il mieux de transmettre individuellement les 4 parametres par reference ou plutot avec une seule variable tableau dont la valeur sera:

Dans le fond c'est sensiblement la même chose que les sprintf.

Tout ça n'a guère d'importance si tu regarde bien, j'ai plutôt tendance à dire de faire comme tu veux, ce qui te parais le plus évident, là où tu te sens le plus à l'aise aussi.
De toute manière, au final c'est ton code, c'est toi qui va y faire la maintenance, le faire évoluer, etc ...
En tout cas, ça va évoluer, tu peux être sûr, donc ce que tu fais aujourd'hui sera fait différemment un jour, peut être même dans peu de temps.


Becarefull sur le terme que tu utilise par reference.
Il y 2 manière de "passer" des paramètres à une fonction.
1/ Par valeur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

function une_fonction($par_valeur) { ... }

Ce qui fait que $par_valeur ne sera accessible QUE dans la fonction, pas en-dehors.
Si sa valeur change dans la fonction ça agira uniquement dans la fonction.

2/ Par référence :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

function une_fonction(&$par_reference) { ... }

C'est le & qui déclare le passage par référence (lors de la création de la fonction).
$par_reference ici est une référence de $par_reference, celle qui appel la fonction en-dehors.
Si sa valeur change dans la fonction, celle en-dehors aussi et aura la même valeur.
C'est franchement pas pareil.
Même comportement que de déclarer global une variable dans une fonction, c'est ce que j'expliquais auparavant.

Donc les paramètres de ta fonction show_amount() passent par valeur et non par référence.
Par contre, si le paramètre passé en argument est un Objet, alors c'est particulier depuis Php5, ça passera par référence. Il ne faut pas rajouter de & à la création de la fonction sinon ça génère une erreur (type déprécié).

[redah75]

Je vais le répéter je sais, mais c'est vraiment dommage que la POO ne soit pas encore connu de ton coté, car c'est ainsi que je ferais, donc ça n'aurait été ni dans la session ni dans des constantes, mais dans des Objets.
Ce genre de projet s'y prête pourtant à la POO, limite indispensable.

entierement d'accord avec toi mais je t'avoue avoir une vrai phobie contre la POO, et je ne sais pourquoi. j'ai meme essayé de m'y mettre mais rien a faire, je comprend rien!! je sais que tu devrais te dire que c'est psychique, c'est un peu comme les piqures, je tombe dans les pommes a chaque prise de sang!

Becarefull sur le terme que tu utilise par reference.
Il y 2 manière de "passer" des paramètres à une fonction.
...

oups, j'avais une mauvaise notion sur les termes a utiliser Et merci pour la bonne explication. je ne me suis jamais servi d'une transmission par reference...
par contre quelle est la meilleure facon d'utiliser une variable en dehors d'une fonction mais créée a l'interieur de la fonction.
j'ai jusqu'a present toujours fait:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
function ma_fonction() {
global $var1;
}

Il y a l'air d'en avoir pas mal, entre les langues et les devises.
Dans des constantes ce n'est pas mal c'est vrai.

j'y songé aussi. mais les 2 variables $current_currency_symbol et
$current_currency_code risquent de changer. le visiteur a la possibilité de changer de devise, et je ne peux donc pas la declarer en constante.
que recommandes tu ??
et puis je me demande s'il est interessant de stocker ces variables dans des sessions ou constantes ou plutot de faire a chaque page une requete SQL pour recuperer ces variables... là encore, je ne sais pas trop vers quel choix m'orienter.!!

[RunCodePhp]

Je t'assure, on ne peux pas répondre à toutes les questions comme ça, ça demande vraiment une vue d'ensemble du projet, voir même se projeter sur 1, 2 voir 3 ans.

De plus, et c'est un point où il me semble avoir déjà évoqué, c'est de regarder comment les autres font, comme les Soft Open Source.
Le seul que je connaisse dans ce secteur e-commer c'est osCommerce, qui à ce jour à une certaine connotation d'ancien.
Par sûr que ça soit la bonne référence.
Mais une toute nouvelle mouture (Objet avec un FrameWork) est sur le point de sortir, à ce qu'il parait, mais je ne connais pas cette dernière.
Mais il n'y a pas que osCommerce, il y en a plein d'autres que je ne connais pas et qui doit valoir le coup d'y jeter un oeil, c'est quasi une certitude.

j'y songé aussi. mais les 2 variables $current_currency_symbol et
$current_currency_code risquent de changer. le visiteur a la possibilité de changer de devise, et je ne peux donc pas la declarer en constante.
que recommandes tu ??

Là encore difficile d'y répondre, car à mon avis les 3 types de stockages seraient à utiliser.
Qu'une donnée comme le "fr" de la langue soit dans la session me semble évident par exemple, et aussi dans la Bdd, car elle vient de là avant tout.

Par contre, pour ce qui relève des format (date, devise), les constantes seraient peut être mieux dan ton cas par exemple.

Par contre, pour que la bonne devise soit récupérer selon la langue, et bien le principe de osCommerce pourrait faire l'affaire par exemple.
Le principe est simple :
Créer autant de fichiers de langue qu'il y a de langue : french.php, english.php
Puis créer des constantes portant le même nom dans chacun des fichiers.
Au bout, ne sera inclus QUE le fichier de langue qui est demandé (ou changé).

Fichier french.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
define('CURR_SYMBOL', '€');

Fichier english.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
define('CURR_SYMBOL', '$');

Un echo sur CURR_SYMBOL dans n'importe quel page ou fonction (à condition d'inclure le fichier langue avant) retournera le bon symbole.


Par contre, l'exemple de la devise n'est pas forcément le meilleur exemple, car la devise ne devrait pas être liée à la langue, c'est assez indépendant.
Un visiteur devrait pouvoir demander une interface en Français, mais vouloir (ou devoir) payer avec la Livre.
Ou demander l'Anglais comme langue et payer en Euro.

Il faudrait peut être prévoir des alternatives sur les devise dans chaque fichiers de langues pour aboutir sur une seule constante (la bonne) du symbole.


Donc sans vouloir vraiment conseiller, adopter des systèmes/concepts simples, rapides, efficaces te permettras de revenir dessus plus tard, une fois que tu auras une vision plus global de ton projet, c'est surement ça que tu ne visualise pas bien.
Enfin, c'est ce que je me dis.

[redah75]

Le principe est simple :
Créer autant de fichiers de langue qu'il y a de langue : french.php, english.php
Puis créer des constantes portant le même nom dans chacun des fichiers.
Au bout, ne sera inclus QUE le fichier de langue qui est demandé (ou changé).

c'est exactement le principe que j'utilise: j'ai adopté cette arborescence:
www --> inc --> lang --> en-us --> global.xml (textes traduits) et config.php (formatage devise, dates et autres)
j'ai aussi 2 autres dossiers, en-gb et fr-fr

car la devise ne devrait pas être liée à la langue, c'est assez indépendant.
Un visiteur devrait pouvoir demander une interface en Français, mais vouloir (ou devoir) payer avec la Livre.

tu as tout compris et c'est ce que je t'ai dit dans mon message precedant. je ne peux pas trop utiliser des constantes pour la devise puisque l'utilisateur peux la changer a tout moment.
j'ai decidé de mettre ces variables en CONSTANTE:
$current_tld
$current_lang_iso_full
$current_lang_iso
$current_lang
$current_country_iso
$current_country

puis celles ci en SESSION:
$current_currency_symbol
$current_currency_code

qu'en penses tu? est ce une bonne idee?

parlant de session, est ce bien securisé?? j'ai lu des truc qui me font flipper au sujet des vols de session. y a t'il des choses a prendre en consideration afin de securiser les session, ainsi proteger l'utilisateur?? j'ai vu qu'il faut regenerer l'identifiant de session avec session-regenerate-id()...

autre petite question que je t'ai posé avant
pour utiliser une variable créée dans une fonction en dehors de cette fonction. le seul moyen est de la declarer en global, c'est ca??

[RunCodePhp]

puis celles ci en SESSION:
$current_currency_symbol
$current_currency_code

Ici, je ne vois pas vraiment l'utilité de mettre ces 2 là en session.
Mets les dans des constantes, et de simples include() basés sur la langue et la devise.
Pour la langue et la devise, il en faudrait juste 4 en sessions genre :
$_SESSION['langue_id'] -> 1
$_SESSION['langue_iso'] -> FR
$_SESSION['currrency_id'] -> 1
$_SESSION['currrency_name'] -> EURO
(peut être 1 ou 2 en plus pour le coté pratique, donc sans exagération).

Après faire en sorte d'inclure les fichiers de langues, devises en se basant sur ces données là, il n'y a que celles ci qui changent si ça change, le reste suivra.
Donc les chaines (FR, EURO) coté fichiers, les IDs (1, 1) coté Bdd.

A savoir qu'il sera utile, voir indispensable d'avoir ces mêmes données en Bdd, ne serait-ce pour des stats, etc ..., donc requêtes SQL.
L'idée qui me semble assez exploitée (j'en fait de même), c'est que uniquement coté partie Admin, de générer automatiquement ces fichiers, ces divers constantes, donc du Php générant du Php.
Ces données ne changeant pas tous les 4 matins, elles seront donc très rarement réactualisés.
Donc coté admin, on fait tout en se basant sur la Bdd (très peu de gens qui y accèdent), et coté site publique (là où il y aura du trafique) on se base sur ces fichiers.
Le but recherché est de soulager la Bdd tout en ayant la possibilité de requêter s'il n'y a pas d'autres moyens, même coté site publique (ça peu être le cas comme sur une page de recherche avancée).


Ne mets en session essentiellement des données proches de l'utilisateur, sinon tu risque d'en avoir de trop, voir en doublons, en plus il faudra tout le temps faire gaffe en cas de changement.
Faut donc bien faire le distingo entre données purement liées à l'interface et les données propre à l'utilisateur, qui par exemple débouchent sur un enregistrement en Bdd (panier, commande, etc ...).

Pour le coté sécurité, il ne faut quand même pas tomber dans la paranoïa.
Il est clair que si on s'appelle FaceBook, Google, etc ... une gestion de session basique ça ne va pas le faire, c'est quasi certain.
Pour ma part il est clair que les risques sont en priorité lié à la notoriété et de l'intérêt que suscite le site Web.
Pour exemple, mon tout 1er site Web c'était "journée porte ouvert 24/24h", ça a duré ~3 ans sans jamais l'ombre d'un piratage.
Normal, pas du tout connue et pas l'ombre d'une donnée personnelle intéressante et pas 1 centime d'euro à gagner.

Le truc c'est qu'il faut éviter de mettre trop d'infos confidentielles, mettre un ID d'utilisateur suffit, les reste sera récupérer pas des requêtes selon cet ID.
Idem pour l'adresse de l'utilisateur, etc ...

Puis tu peux trouver des système basés sur des jetons souvent pour renforcer un peu plus les choses, le but étant de faire en sorte d'être un peu plus sûr d'avoir affaire à la même personne.
Si on estime que les risques sont élevés, que les données ou services proposés sont sensibles, le SSL est un moyen de renforcer la sécurité.

Mise à part ça, avoir un gestionnaire personnel pour les sessions (voir entre autre la fonction session_set_save_handler), et les mettre en Bdd peu apporter un supplément coté sécurité.
Enfin, c'est ce que je pense, à chacun sa manière de voir les choses.

pour utiliser une variable créée dans une fonction en dehors de cette fonction. le seul moyen est de la declarer en global, c'est ca??

Oui, mais que ça création soit à l'origine dans une fonction, c'est un peu limite limite.
Normalement, ou du moins la logique veut que l'on déclare une variable en global pour faire référence de celle à l'extérieur, donc sous entendu quelle existe déjà.
Pour faire les choses proprement, il faudrait la créer/initialiser à l'extérieur avant, quitte à le faire à la ligne qui précède l'appel à la fonction.

[redah75]

Ici, je ne vois pas vraiment l'utilité de mettre ces 2 là en session.
Mets les dans des constantes, et de simples include() basés sur la langue et la devise.
Pour la langue et la devise, il en faudrait juste 4 en sessions genre :
$_SESSION['langue_id'] -> 1
$_SESSION['langue_iso'] -> FR
$_SESSION['currrency_id'] -> 1
$_SESSION['currrency_name'] -> EURO
(peut être 1 ou 2 en plus pour le coté pratique, donc sans exagération).

je veux les mettre en session car elles peuvent changer plusieurs fois pendant la visite du site web. je pense que je vois sur quoi on se comprend pas
je ne peux pas lier la devise a la langue, et ca tu l'as dit avant... les format des devises doit figurer dans un fichier commun a toutes les langues.
je mets les devises (systeme) en constante comme tu dis, puis je DOIS mettre en session la devise de l'utilisateur. et puis pour afficher la bonne devise choisie par l'utilisateur, je mets un truc du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo constant('CURR_' . strtoupper($_SESSION['devise_utilisteur'])); // CURR_USD ou CURR_EUR...

Le truc c'est qu'il faut éviter de mettre trop d'infos confidentielles, mettre un ID d'utilisateur suffit, les reste sera récupérer pas des requêtes selon cet ID.
Idem pour l'adresse de l'utilisateur, etc ...

effectievement, je ne garde en session que 2 infos sur l'internaute:
1- si identifié
2- identifiant de l'utilisateur
et puis au besoin, une requete pour recuperer les données relatives a l'utilisateur...

Puis tu peux trouver des système basés sur des jetons souvent pour renforcer un peu plus les choses, le but étant de faire en sorte d'être un peu plus sûr d'avoir affaire à la même personne.
Si on estime que les risques sont élevés, que les données ou services proposés sont sensibles, le SSL est un moyen de renforcer la sécurité.

oui biensur que j'aurais un certificat SSL, toute la rubrique "compte" et page d'identification ainsi que la page de contact où l'internaute donne son email seront en https.
parlant de jeton, penses tu que c'est interessant de rajouter la verification de l'adresse ip?
pour l'instant, quand tu t'identifies sur mon site, je stock en session une variable $_SESSION['indentifie'] = "ok"; et puis dans les pages a acces restreint, je me contente de verifier cette variable de session!
j'ai pensé a faire ceci:
quand tu t'identifies sur le site, je stock en session $_SESSION['indentifie'] = "ok" et $_SESSION['ip'] = $_SERVER['REMOTE_ADDR']
puis dans les pages restreintes, je verifie si $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];

qu'en penses tu?

[RunCodePhp]

je veux les mettre en session car elles peuvent changer plusieurs fois pendant la visite du site web

Le changement de devise ou de langue reste néanmoins un faux problème.

Par contre, j'admets avoir commis une erreur en donnant un exemple où les devises seraient dans les langue.

Donc on est d'accord que les devises n'ont aucun rapport, aucun liens avec la langue.
Du coup, comme tu as adopté le même principe d'inclusion des données de langues (même si les noms diffères un peu), et bien pourquoi ne pas adopter exactement le même principe pour les devises ?

Pour faire simple en reprenant mon exemple précédent.
Ca déboucherait sur ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
// Les données de sessions qu'on a sous le coude
//$_SESSION['langue_iso'] -> fr
//$_SESSION['currrency_name'] -> euro
 
// La langue : 
include('lang/'.$_SESSION['langue_iso'].'.php');
 
// La devise
include('devise/'.$_SESSION['currrency_name'].'.php');

En partant du principe qu'on aurait les répertoires et fichiers genre :
Pour les langues : .../lang/fr.php et .../lang/en.php et .../lang/us.php ... etc ...

Pour les devises : .../devise/euro.php et .../devise/livre.php et .../devise/dollar.php ... etc ...

Ne sera donc inclus qu'1 seul et unique fichier de langue, de même qu'1 seul et unique fichier pour la devise (des constantes).
Donc juste ce qu'il est nécessaire.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo constant('CURR_' . strtoupper($_SESSION['devise_utilisteur'])); // CURR_USD

Ici, ça suppose qu'il faille en 1er stocker en mémoire toutes les divers devises, et du faite qu'on les a tous, une sur-couche de code (fonction constante) est nécessaire pour accéder à celle de l'utilisateur.
Au final : plus de mémoire utilisées, des traitements supplémentaires aussi.

Maintenant, si dans ton fonctionnement il est prévu (ne serait-ce qu'une fois) d'afficher cote à cote par exemple un tarif dans 2 devises différentes, alors effectivement ça change tout.
Mais ce n'est pas ce que j'ai compris, faut voir.

Concernant la sécurité au niveau des sessions, c'est franchement un gros morceau, il y a beaucoup trop à dire.
Rien que sur ce forum il y a plein d'infos :
- Faq session
- Cours session
Une recherche sur GG avec des mots du genre "php session sécurité", il y a des choses intéressantes.

Déjà, je n'est pas les compétences suffisantes, il me semble bien t'avoir dit une fois (autre topic) que je ne suis pas un pro, le développement n'est pas mon métier. Pure amateur quelque peu passionné de ce domaine là.

Puis aussi, tu as quelque peu l'art et la manière de traiter plusieurs sujets dans un seul topic.
Je t'assure, tu aurais bien plus retours en créant plusieurs topic par sujet ou thème ... des solutions et avis différents, etc ...

Bon, je suis du genre bavard quand je m'y mets, t'as de la chance, mais ce n'est que mon avis, c'est plutôt limité, non ?

[redah75]

Ne sera donc inclus qu'1 seul et unique fichier de langue, de même qu'1 seul et unique fichier pour la devise (des constantes).
Donc juste ce qu'il est nécessaire.

ah ouiiii, j'y ai pas pensé. peut etre parce que je voulais limiter les appels de fichiers...
je vais foncer pour la solution que tu m'as donnée

Puis aussi, tu as quelque peu l'art et la manière de traiter plusieurs sujets dans un seul topic.
Je t'assure, tu aurais bien plus retours en créant plusieurs topic par sujet ou thème ... des solutions et avis différents, etc ...

hehe je t'assure que c'est pas le cas: une chose en rappelle une autre

on, je suis du genre bavard quand je m'y mets, t'as de la chance, mais ce n'est que mon avis, c'est plutôt limité, non ?

pas du tout, j'apprends beaucoup de choses avec toi

et puis que penses tu du truc de l'adresse ip dont je t'ai parlé???

[RunCodePhp]

et puis que penses tu du truc de l'adresse ip dont je t'ai parlé???

Comme ça, je dirais que ce serait trop basique, mais mes connaissances sur le sujet sont très limités, je ne connais franchement rien coté réseau, on peu pas tout savoir.

La seule chose que j'ai pu comprendre, ou l'impression assez général concernant les IPs, c'est que ce n'est pas une donnée très fiable, donc quelque peu casse gueule selon ce qu'on fait.
Du coup, j'utilise un code qui vient d'un FrameWork, mais avec le temps, je ne sais plus lequel
Un de ces 4 faudrait d'ailleurs que je rajoute d'où sont basés mes codes, car ils viennent de partout, et je se sais plus après

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
    /**
     * Tente de récupérer l'adresse IP réelle derrière un proxy
     *
     * @static
     * @access public
     * @return string  IP address.
     * @throws Exception si l'adresse IP semble invalide.
     */
    protected static function setUserIP() {
        $realIP = '';
        $httpXForwardedFor = '';
        if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
            $httpXForwardedFor = $_SERVER['HTTP_X_FORWARDED_FOR'];
        }
        //
        if (!empty($httpXForwardedFor)) {
            if (strpos($httpXForwardedFor, ',') !== FALSE) {
                $ips = array_reverse(explode(', ', $httpXForwardedFor));
            }
            else {
                $ips[] = $httpXForwardedFor;
            }
            //
            foreach ($ips as $i => $ip) {
                if (preg_match('~^((0|10|172\.16|192\.168|255|127\.0)\.|unknown)~', $ip) != 0) {
                    continue;
                }
                $realIP = trim($ip);
                break;
            }
            //
            if (empty($realIP)) throw new Exception('[1] Adresse IP non valide.', E_USER_ERROR);
        }
        else {
            $realIP = $_SERVER['REMOTE_ADDR'];
        }
        //
        $userIP = ip2long($realIP);
        if ($userIP == FALSE) throw new Exception('[2] Adresse IP non valide.', E_USER_ERROR);
        //
        //return strval($userIP);
        self::$ip_address = strval($userIP);
    }

Comme tu peux voir, c'est un peu différent, ça prend en compte le cas où une personne serait sur un réseau (en gros).

Aussi, j'ai lu il y a peu sur ce même forum (celui des Session il me semble) que le réseau 3G pouvait semer la zizanie, du moins sur l'hébergeur OVH ça peu être un problème.
Mais bon, sous réserve, j'ai jamais vérifier (je ne suis pas sur OVH de toute manière).

En gros, si on enregistre en session l'adresse IP (en admettant qu'on obtienne la bonne), et que celle ci change lors de la 2ème page demandée alors que c'est bien la même personne, alors ton code risque de déboucher sur une erreur, ou considérer ça comme une tentative de piratage (incohérence entre celle obtenue et celle en session) alors qu'il en est rien.
Le cas peut être rare, mais c'est ce que fait ce code.
Donc ???

Mais j'en fais tout autant, que cela soit dit.

[redah75]

eh ben! rien n'est finalement simple!!

En gros, si on enregistre en session l'adresse IP (en admettant qu'on obtienne la bonne), et que celle ci change lors de la 2ème page demandée alors que c'est bien la même personne, alors ton code risque de déboucher sur une erreur, ou considérer ça comme une tentative de piratage (incohérence entre celle obtenue et celle en session) alors qu'il en est rien.

tu penses que cela peut arriver??

Du coup, j'utilise un code qui vient d'un FrameWork, mais avec le temps, je ne sais plus lequel

je comprends que toi aussi tu utilises cette methode. as tu eu des soucis avec??
sinon quelle autre methode utilises tu?
et pourquoi ne pas utiliser tout simplement $_SERVER['REMOTE_ADDR'] ??

en faisant des recherches, j'ai vu que certains interrogent la base de donnees sur chaque page pour s'assurer que c'est bien le bon utilisateur qui est identifié!!
qu'en penses tu?

[RunCodePhp]

eh ben! rien n'est finalement simple!!

Je ne sais quand est ce que tout cela me semblera limpide ou simple, mais jusqu'à lors, plus j'avance, plus je découvre que à chaque fois plus compliqué, plus subtil que ça n'y parait.
Il y a de forte chance que tu en face la même conclusion.

A un moment donné je me suis que ça y est, les choses ont l'air de se stabiliser.
Pas d'bol, entre le HTML5 qui se profile ou autre FrameWork, les nouveaux supports tel que smartphone, tablette pc, (rien que ça) ... seront sans nulle doute de nouveaux standard ne va rien arranger du tout.
Faut sans cesse se réactualiser, pas le temps de s'ennuyer.
C'est ce qui me plait aussi dans ce domaine, faut l'dire.

Ceux qui ne prennent pas le train en route, et bien ils resteront sur le trottoir, sans nulle doute aussi.
Sinon, leur restera quand même la solution de payer un Soft clé en main.

tu penses que cela peut arriver??

Apparemment c'est ce qui est arrivé.
Mais j'ai jamais remarqué ça de mon coté cependant.
Faudra rester vigilant, toujours rester informer (forum, blog, etc ...)


Concernant les sessions, et particulièrement l'aspect sécurité, je préfère ne pas m'étendre la dessus, encore une fois, je n'ai pas les connaissances suffisantes, tout bêtement.
C'est simple, car pour pouvoir coder ce qu'il faut pour "contrer" toutes les divers actes de piratages, et bien il faut connaitre les techniques, donc être quelque part un pirate.
Je ne suis absolument pas un pirate, et ça m'intéresse même pas.

De plus, je n'est pas du toutes les même contraintes que toi, donc mon code sur ce point est assez basique, et jusqu'à lors, j'ai jamais eu de problème.
Mais c'est quelque part normal.

Le seul point où on peu dire que c'est un peu évoluer, c'est la gestion des sessions, qui est entre autre gérer dans la Bdd.
La gestion des sessions n'est pas un mécanisme de sécurité, c'est fait pour obtenir plus de souplesse, plus de possibilités, comme toutes autres données en Bdd.
Ceci dit, je pense quand même que le fait que les sessions ne sont plus dans des fichiers (gestion par défaut), amène indirectement à un petit plus coté sécurité.

Mais l'aspect sécurité ne serait ce que pour les sessions c'est un ensemble de solutions, de petits trucs les uns rajoutées aux autres.
Mais de mon coté, je n'est pas fait grand chose de plus que ce qui ce fait couramment.
Même le système de jeton je ne l'ai pas fait, c'est assez courant apparemment.

Pour le REMOTE_ADDR, c'est expliqué entre autre en commentaire dans le code, de même qu'il me semble que le code est assez explicite.
C'est pour tenter de récupérer l'IP dans le cas où il y aurait un proxy.
Si lors des successions de visite de page cet IP venait à changer, et bien il y aura une incohérence entre l'IP obtenue et celle enregistrée dans la session de la visite précédente, donc au bout le code estimera qu'il y acte de piratage.
Même problème que j'évoquais auparavant.
Il me parais donc normal qu'il faille faire le nécessaire pour récupérer la bonne IP (enfin, du mieux que possible).
Mais à part me baser sur des codes que d'autres ont "plancher" dessus, mes connaissances réseaux (+ ne pas être un pirate) ne sont pas suffisantes pour dire que telle où telle solution est meilleure.

j'ai vu que certains interrogent la base de donnees

Quelle Bdd ? De quelles données s'agissait il ?

Pour ma part, il ne faudrait pas confondre l'identification d'un utilisateur via un login/pas par exemple et l'utilisateur en tant que poste client (le navigateur, moteur de recherche, ou autre pompeur de contenu y compris un pirate).
Ce n'est pas du tout la même chose.
Le plus important à mon sens, c'est d'arriver à dire qu'on a toujours affaire au même poste client (je réduis au navigateur pour faire simple), et ça tout au long de sa navigation.
La plus grosse part d'insécurité, la grosse inconnue, ce trouve là à mon sens.
On a un mal de chien à avoir la certitude que les infos que l'on reçois de la part du poste client soient correctes, cohérentes. (celles qui sont dans $_SERVEUR entre autre).

Si on a un code foireux à ce niveau là, genre un pirate se faisant passer pour un autre poste client valide, et bien on aura beau interroger une Bdd 100 fois de suite que ça ne changera pas grand chose.

Le principe des sessions/cookie est basé la dessus, et à ma connaissance on peu guère faire autrement (du principe général j'entends).
Le problème, c'est ce fichu cookie où l'incertitude est assez importante.

Tant qu'il n'y aura pas un jour une donnée venant du poste client dont le plus balaise des pirates ne pourra pas agir dessus, et ça du début (poste client) jusqu'à la fin (serveur), et bien le doute persistera.
Il est là le fond du problème à mon sens.


Enfin, à moins de ne pas avoir saisie ce que tu voulais dire.

[redah75]

Je ne sais quand est ce que tout cela me semblera limpide ou simple, mais jusqu'à lors, plus j'avance, plus je découvre que à chaque fois plus compliqué, plus subtil que ça n'y parait.
Il y a de forte chance que tu en face la même conclusion.

j'y suis deja arrivé a cette conclusion. plus tu avances, plus tu te rends comptes des complications a gerer, plus tu te rend aussi compte que ca n'en finit JAMAIS!!

Quelle Bdd ? De quelles données s'agissait il ?

j'ai lu hier un tuto qui evoquait cette solution.
il s'agit en effet d'un principe simple.
1- tu t'identifies en saisissant un email et mot de passe
2- tu mets dans un tableau de SESSION les valeurs 'email' et 'mot de passe' crypté
3- dans chaque page "privée" où il faut etre identifié, on ne se contente pas de simplement verifier si $_SESSION['email'] && $_SESSION['mot_de_passe'] existent, mais on interroge egalement la base de données pour verifier si l'email et le mot de passe en SESSION correspondent

sauf que moi, le probleme c'est que je ne stock pas l'email et le mot de passe en session, je stock uniquement son identifiant. je peux peut etre juste verifier si l'identifiant existe. qu'en penses tu??
mais est ce que cela est une bonne pratique? je ne sais pas!! cela ne risque t il pas de surcharger le serveur?? j'en sais rien!!
je t'avoue etre encore une fois largué, je ne sais trop quoi faire et j'aimerais quand meme pas developper une usine a gaz!

je suis entrain de revoir mes scripts pour la bonne integration de la devise et je suis entrain de suivre ta solution. ca l'ai de marche mais un petit truc m'intrigue.
j'ai créé un dossier "devise" qui contien 3 fihiers "EUR.php", "GBP.php" et "USD.php" qui respectivement contiennent le code suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<?php
define("NUM_DECIMAL", ",");
define("NUM_THOUSANDS", " ");
define("CURR_SYMBOL", "&euro;");
define("CURR_CODE", "EUR");
define("CURR_RATE", 1.2);
define("CURR_FORMAT", '%1$s %2$s');
?>
 
<?php
define("NUM_DECIMAL", ".");
define("NUM_THOUSANDS", ",");
define("CURR_SYMBOL", "&pound;");
define("CURR_CODE", "GBP");
define("CURR_RATE", 1);
define("CURR_FORMAT", '%2$s%1$s');
?>
 
<?php
define("NUM_DECIMAL", ".");
define("NUM_THOUSANDS", ",");
define("CURR_SYMBOL", "$");
define("CURR_CODE", "USD");
define("CURR_RATE", 1.6);
define("CURR_FORMAT", '%2$s%1$s');
?>

et puis avec verification que la devise existe etc... j'inclus le fichier a l'aide d'un include_once.

lorsqu'on choisit une devise, la page se recharge et appelle le bon fichier.php mais je croyais que j'allais quand meme avoir une erreur du type "NUM_DECIMAL already defined"
est ce normal que ca marche??

[RunCodePhp]

j'y suis deja arrivé a cette conclusion. plus tu avances, plus tu te rends comptes des complications a gerer, plus tu te rend aussi compte que ca n'en finit JAMAIS!!

C'est pour ça qu'utiliser des Soft genre Open Source est une solution à ne pas éliminer, car les problèmes ont été pensés par plusieurs personnes, des mecs balaises, entre autre l'aspect sécurité.

dans chaque page "privée" où il faut etre identifié, on ne se contente pas de simplement verifier si $_SESSION['email'] && $_SESSION['mot_de_passe'] existent, mais on interroge egalement la base de données pour verifier si l'email et le mot de passe en SESSION correspondent.

Je ne vais pas passer par 4 chemins, pour ma part c'est le plus mauvais système qui soit, pure bêtise.

C'est marqué noir sur blanc dans la doc de php : Il faut éviter (voir proscrire) de mettre des données sensibles, confidentielles dans les sessions, on ne cesse de dire dans tous le forums, ça relève du BABA de la sécurité.
Et bien mettre un couple login/passe, on peu difficilement faire pire.
Donc quand tu vois ça, faut partir en courant.

Franchement, c'est grave, ce genre de truc ne devrait pas exister sur le Net, d'autant plus que ça se veut être plus sécurisé que les autres, c'est l'un coté négatif du Net, c'est qu'on y trouve un peu tout et n'importe quoi.

Le fait que les email/passe soient cryptés/hachés ne change strictement rien au problème, franchement rien, et ça dénote explicitement que ceux qui font ça n'ont toujours pas compris où se trouve le vrai problème.
Et le fait de requêter à chaque fois pour faire une vérif n'est qu'une absurdité de plus, faut l'dire.


Le fond du problème est ailleurs, et il est directement lié au poste client, ce que renvoie le navigateur vers le serveur.
Que les données dans les sessions soient cryptés résout effectivement 1 problème, mais 1 seul, celui qu'un pirate parvienne à récupérer et lire des fichiers de sessions.
Mais ce n'est pas le seul et unique acte de piratage possible, d'ailleurs, bien malin celui qui sait quels sont ces différentes techniques de piratages, et bien malin celui qui trouvera toutes les parades.
En tout cas, les FaceBook, Google, etc ... se font régulièrement piratés leur données, suffit de lire l'actu, ce ne sont pas des guignoles pourtant, ça dénote la grosse difficulté qu'il y a dans ce domaine à sécuriser des données.


Je l'ai déjà dis, tout l'art repose sur le fait d'avoir la certitude que c'est le même, le bon poste client (sous entendue la même personne et la bonne utilisant un navigateur).

Là ou je n'étais peut être pas très explicite, c'est que tout le principe repose sur un seul et banal cookie.
C'est ce fichu cookie qui pose problème, car si on a une gestion de session par défaut, donc un simple session_start(), on laisse le serveur être le seul et unique juge pour dire que le cookie obtenu dans l'entête de la requête HTTP correspond à un fichier de session.
S'il juge que ça correspond, donc que tout est Ok, les données en session seront dispo dans le $_SESSION.

Pourquoi rajoute t-on une vérification sur l'IP ?
Pour la simple raison qu'on estime que l'info reposant sur le cookie est insuffisante. On se base donc sur une 2ème donnée venant du poste client pour mettre une couche supplémentaire.

Pourquoi certains utilisent un système de jeton ?
Pour la même raison. Si on additionne tout ça, ça fait 3 couches basées sur des données du poste client (cookie, IP, jeton/user_agent).
Le système de jeton, même si je ne le connais pas bien encore, c'est un 2ème cookie (donc déjà là c'est un 2ème élément venant du poste client) où la valeur est hachée (sha1 en général) qui est apparemment basée sur le HTTP_USER_AGENT concaténé de la date en court.
Donc la valeur de ce jeton change à chaque visite, à la différence de celui qui correspond à la session dont la valeur est la même tout le temps, ça doit l'être en tout cas tout comme l'IP.
Ca rajoute donc une couche supplémentaire, de plus elle change, donc une difficulté pour un pirate (au moins pour le pirate du Dimanche).
En gros c'est pas mal, et il ne me semble pas que ça soit si usine à gaz que ça.
Ca vaut le coup de se pencher la dessus, chose que je n'est pas fait totalement faute de temps.

Mais encore une fois, tout ceci se base toujours sur des données venant du poste client, ça ne peut pas être autrement, car l'insécurité vient de là.
Donc tout ce qui se fera après est un tout autre problème, ça n'a aucun rapport.
Si cette 1ère phase n'est pas fiable, on aura beau faire tout ce qu'on veut après, ça ne sera que du vent.
Le problème du Net réside là.


C'est quelque par le même problème que le SSL, ça rajoute une sécurité supplémentaire, c'est certain, mais à elle toute seule elle ne vaut pas grand chose.
Si un pirate parvient à prendre "la main" à l'insu d'une personne, et bien le SSL ne le détectera pas.
Et si ce pirate détient toutes les infos de la carte bancaire de la personne, et bien là encore rien ne l'empêchera d'effectuer un achat.


Petite parenthèse donc concernant cet ID de client dans la session, et bien ceci n'est là que pour la persistance, donc conserver une donnée tout au long de la navigation.
On met un ID car ça n'évoque pas grand chose à la différence d'un mail/mot de passe (même haché).
Une requête sera quand même faite si on souhaite obtenir son mail, nom, etc ...
Ensuite, on vérira quand même ce que retourne la requête, qu'un client correspond à cet ID.
Mais ici ce n'est pas de la sécurité à proprement parlé, c'est plus pour rendre son appli plus fiable.
Si aucun client ne correspond -> erreur (retour à la page d'accueil par exemple).

est ce normal que ca marche??

Bien sûr que c'est normal.
C'est bizarre que tu coince la dessus vu que tout est en place.

Le principe, "le truc", repose sur 2 choses :
- Inclure 1 seul et unique fichier (parmi plusieurs), surtout pas 2, encore moins 3.
- Que les noms des constantes soient strictement identiques dans tous ces fichiers.

Vu qu'1 seul fichier sera inclu, les constantes seront chacune uniques, donc on aura pas cette erreur de constante déjà définie.
C'est tout simple, faut pas chercher la petite bête là où il y en a pas.


A coté de ça, faire un "include_once" d'une part ne sert à rien, de plus, l'approche au problème n'est pas le bon.
Ici, tu fait quelque part tout pour qu'un 2ème fichiers (fr + en par exemple) ne soit pas inclus.
Pourquoi pas.
Mais un "require()" dans l'approche serait mieux, car s'il venait à avoir un bug, donc inclure un 2ème fichier, on tentera de créer une 2ème constante du même nom.
Et bien il est préférable d'être au courant de cette erreur plutôt que ne rien inclure, donc de laisser filer les choses sans encombre.
Pourquoi ?
Et bien qu'est ce qu'il dit que le 1er fichier inclus est le bon ?
Pourquoi ça ne serait pas plutôt le 2ème à inclure et pas le 1er ?
Et bien rien, vois tu ?

Et c'est là qu'on arrive sur un énième autre sujet, la gestion des erreurs.
Autre aspect tout aussi complexe que la sécurité, site multilangue, etc ...

Donc ne jamais être au courant d'un bug oblige à soit même faire tous les test possibles et inimaginables (le inimaginable est presque le plus important) pour tomber sur ce bug.
En tout cas, il ne faut théoriquement pas compter sur tes visiteurs (ou clients) pour t'en avertir.
Pour ma part, la plupart iront voir ailleurs, en tout cas, c'est ce que je fais, je ne commande pas sur un site bugguer.

[redah75]

Merci pour cette reponse bien detaillée!

Je ne vais pas passer par 4 chemins, pour ma part c'est le plus mauvais système qui soit, pure bêtise.

C'est marqué noir sur blanc dans la doc de php : Il faut éviter (voir proscrire) de mettre des données sensibles, confidentielles dans les sessions, on ne cesse de dire dans tous le forums, ça relève du BABA de la sécurité.
Et bien mettre un couple login/passe, on peu difficilement faire pire.
Donc quand tu vois ça, faut partir en courant.

hehe, c'est bien ce que j'ai fait, mais j'ai neanmoins retenu l'idee d'interroger la base sur chaque page mais qui apparement n'est pas une bonne idee...

selon d'autres recherches que j'ai faite hier, je suis arrivé a une conclusion pas mal, t'en as partiellement parlé, je suppose donc qu'elle est pas mal, mais je suis sur que tu me sortiras des contres exemples...

au moment de l'identification, je mets en SESSION $_SERVER['SERVER_NAME'] et $_SERVER['HTTP_USER_AGENT'].
et puis dans chaque page "privée" je verifie si $_SERVER['SERVER_NAME'] == "domaine.com" && !empty($_SERVER['HTTP_USER_AGENT']) pour s'assurer que le visiteur est bien connecte d'un navigateur et non pas un terminal ou autres...

Pourquoi certains utilisent un système de jeton ?
Pour la même raison. Si on additionne tout ça, ça fait 3 couches basées sur des données du poste client (cookie, IP, jeton/user_agent).
Le système de jeton, même si je ne le connais pas bien encore, c'est un 2ème cookie (donc déjà là c'est un 2ème élément venant du poste client) où la valeur est hachée (sha1 en général) qui est apparemment basée sur le HTTP_USER_AGENT concaténé de la date en court.
Donc la valeur de ce jeton change à chaque visite, à la différence de celui qui correspond à la session dont la valeur est la même tout le temps, ça doit l'être en tout cas tout comme l'IP.
Ca rajoute donc une couche supplémentaire, de plus elle change, donc une difficulté pour un pirate (au moins pour le pirate du Dimanche).
En gros c'est pas mal, et il ne me semble pas que ça soit si usine à gaz que ça.
Ca vaut le coup de se pencher la dessus, chose que je n'est pas fait totalement faute de temps.

je vois un peu le principe et ca me tente bien. aurais tu un lien pour une explication detaillée stp ??

Bien sûr que c'est normal.
C'est bizarre que tu coince la dessus vu que tout est en place.
...
Inclure 1 seul et unique fichier (parmi plusieurs), surtout pas 2, encore moins 3.
- Que les noms des constantes soient strictement identiques dans tous ces fichiers.

je ne coince pas, et j'inclus bien qu'un seul fichier et les noms de variables sont bien les memes. c'est juste que je pensais que j'allais avoir une erreur du fait que par exemple sur une page j'ai define("var1", "valeur 1") et que sur une autre page pour une autre devise var1 vaudra "valeur 2". mais sinon la technique est genial, t'en remercie

parlant de CONSTANTE, penses tu que c'est mieux de mettre en constante le taux de change pour calculer par la suite la conversion de devise en PHP ou plutot tout faire en SQL lors de l'affichage des prix?
je te pricise que je vais utiliser la livre comme devise par defaut et que j'ai une table "devises" qui contient les 3 devises que j'utilises avec un champ "taux"

A coté de ça, faire un "include_once" d'une part ne sert à rien, de plus, l'approche au problème n'est pas le bon.

erreur de ma part, j'utilise des require_once et non pas include_once