redirection header

C'est AMHA une mauvaise raison pour faire ce qui devrait être fait de
toutes façons. La bonne raison étant que c'est encore ce qui respecte le
mieux la norme HTTP. Et accessoirement, ça évite le problème de la
re-soumission de formulaire par retour à la page précédente...

Excuse moi, mais je n'ais pas tres bien compris ce que tu voulais dire...
Tu veux dire qu'il y a une bonne raison pour utiliser les header dans
mon cas ?
Et je ne comprend pas cette histoire de re soumission des formulaire, je
n'ais jamais eu ce probleme...

C'est AMHA une mauvaise raison pour faire ce qui devrait être fait de
toutes façons. La bonne raison étant que c'est encore ce qui respecte le
mieux la norme HTTP. Et accessoirement, ça évite le problème de la
re-soumission de formulaire par retour à la page précédente...

Excuse moi, mais je n'ais pas tres bien compris ce que tu voulais dire...
Tu veux dire qu'il y a une bonne raison pour utiliser les header dans
mon cas ?

En bref : oui. A défaut d'être une application stricte de la norme HTTP,
c'est ce qui en respecte le plus l'esprit, et ce qui évite le plus de
problèmes.

Après, il ne s'agit pas d'en faire une religion. La norme HTTP n'étant
de toutes façons respectée par à peu près aucun user-agent à ce jour -
et la grande majorité des "développeurs web" ne l'ayant jamais lue -,
c'est plus une "moins pire pratique" (je n'ose parler de "bonne
pratique" dans ce cas) qu'autre chose, et c'est à nuancer en fonction
des cas concrets.

Et je ne comprend pas cette histoire de re soumission des formulaire, je
n'ais jamais eu ce probleme...

Si suite à une requête POST tu retournes un 200 et que l'utilisateur
utilise la fonction "page précédente" de son navigateur, la même requête
POST sera à nouveau soumise. En général, le navigateur averti
l'utilisateur et lui demande confirmation, mais c'est un peu
insuffisant. Une célèbre application de e-commerce open-source permet
ainsi à un utilisateur de payer deux fois la même commande...

Mes deux centimes.

Si suite à une requête POST tu retournes un 200 et que l'utilisateur
utilise la fonction "page précédente" de son navigateur, la même requête
POST sera à nouveau soumise.

Je crains le pire.

En général, le navigateur avertit
l'utilisateur et lui demande confirmation, mais c'est un peu
insuffisant.

Et comment que c'est insuffisant. Ce n'est pas au navigateur de vérifier
qu'on ne fait pas deux fois la même requête. C'est au serveur, bien sûr.

Une célèbre application de e-commerce open-source permet
ainsi à un utilisateur de payer deux fois la même commande...

J'avais raison de craindre le pire. Si l'application ne contrôle pas ce
cas *côté serveur*, ce n'est pas un header("Location") qui empêchera les
requêtes d'être faites deux fois. Ou dix fois. Ou mille fois.

Oui, je sais, autoincrément toussa... ce point n'aurait-il pas par
hasard été déjà traité dans l'excellent document de john Gallet,
http://www.saphirtech.com/p5/web_dynamique.pdf ?

C'est AMHA une mauvaise raison pour faire ce qui devrait être fait de
toutes façons. La bonne raison étant que c'est encore ce qui respecte le
mieux la norme HTTP. Et accessoirement, ça évite le problème de la
re-soumission de formulaire par retour à la page précédente...

fatigué, le garçon. Je voulais dire : par rechargement de la page...

Si suite à une requête POST tu retournes un 200 et que l'utilisateur
utilise la fonction "page précédente" de son navigateur, la même requête
POST sera à nouveau soumise.

NB : cf correctif dans un autre post : je voulais bien sûr parler du
rechargement de la page, pas du retour à la page précédente...

Et évidemment, ça n'exclue en rien les vérifs côté serveur. Ca évite
juste une cause courante d'"accident".

Le probleme, c'est que dans ce cas, je me retrouve avec les droits d'un
script sur un autre...

Chaque script à ses propres droits, et si j'inclu un script dans un
autre avec cette métode, ce ne seronts pas les bons droit qui
s'appliqueronts.

En plus, autre problème : dans chauqe script, je fait un
require('fonctions.php'), et si je fait l'include d'un script dans un
autre, paf, erreur puisque il me dit qu'il ne peut pas redéclarer des
fonctions déjà déclaré...

Pas de solution à proposer pour ce cas ? parceque franchement, je suis
pres à passer à une autre méthode, je n'aime pas bien utiliser des
techniques déprécié, mais par rapport à mon cas, je ne vois pas comment
faire autrement...

Pas de solution à proposer pour ce cas ? parceque franchement, je suis
pres à passer à une autre méthode, je n'aime pas bien utiliser des
techniques déprécié, mais par rapport à mon cas, je ne vois pas comment
faire autrement...

Je n'en sais rien, "chez moi ça marche". Je gère des droits différents
pour chaque page d'admin (plus la propriété des données), l'équivalent de
root faisant "su" pour qu'un administrateur central puisse se substituer à
n'importe quel administrateur régional et executer *exactement le même
code* à la définition des droits près, et je n'ai jamais eut aucun
problème de type redéfinition de constante.

Autre point : il est évident (?!) que les droits associés à la session
comme les droits nécessaires à la fonctionnalité demandée pour la page ne
transitent JAMAIS vers le navigateur et sont EXCLUSIVEMENT conservés côté
serveur... sinon n'importe quel guignol prend les droits qu'il veut.

Je reçois une requête me disant "exécute telle action" par http, je
regarde quel niveau d'accès il faut par rapport à cette action dans la
configuration de l'application, je regarde les droits d'accès associés à
la session courante, si c'est bon j'exécute, sinon c'est
exit(require('fuckyou.php')); et quoi qu'il en soit, à la fin de
l'exécution, j'affiche le résultat et la "page suivante" avec des liens /
formulaire qui contiennent évidemment (?) uniquement l'identifiant de
session. Donc je ne vois vraiment pas comment on peut se touiller les
crayons.

a++;
JG

Autre point : il est évident (?!) que les droits associés à la session
comme les droits nécessaires à la fonctionnalité demandée pour la page ne
transitent JAMAIS vers le navigateur et sont EXCLUSIVEMENT conservés côté
serveur... sinon n'importe quel guignol prend les droits qu'il veut.

Pour ma part, je stoque les droits dans la session... est-ce la bonne
manière de faire ? si non, quelle autre solution ais-je ?

Je reçois une requête me disant "exécute telle action" par http, je
regarde quel niveau d'accès il faut par rapport à cette action dans la
configuration de l'application, je regarde les droits d'accès associés à
la session courante, si c'est bon j'exécute, sinon c'est
exit(require('fuckyou.php')); et quoi qu'il en soit, à la fin de
l'exécution, j'affiche le résultat et la "page suivante" avec des liens /
formulaire qui contiennent évidemment (?) uniquement l'identifiant de
session. Donc je ne vois vraiment pas comment on peut se touiller les
crayons.

Pour ma part, chaque action est dans un fichier diférents, et les
fichier sont stocké dans des répertoires, dans lequel je rajoute un
fichier droit.php, qui contient la constante qui défini le droit
nécessaire pour executer le script. et tous les script font un require
sur le fichier droits.php qui est dans leur repertoire. Chaque droit est
un nombre premier, et les droits de l'utilisateur est un facteur de tout
les droits qu'il a. Donc en fait, les droits sont géré par répertoires,
et la séparation des script me facilite la maintenance... Apres, est-ce
une bonne mani_re de faire ?

Bonjour,

Pour ma part, je stoque les droits dans la session... est-ce la bonne
manière de faire ? si non, quelle autre solution ais-je ?

Oui, nécessairement liés à la session, quel que soit son mode de stockage.

les droits qu'il a. Donc en fait, les droits sont géré par répertoires,
et la séparation des script me facilite la maintenance... Apres, est-ce
une bonne mani_re de faire ?

Sur le fond, oui, c'est (aussi) une bonne manière de faire. Après si tu
fais un reset des données mémoire locale au script par un header location
(qui implique un ping pong http) tu ne te poses pas de questions car toute
exécution de script "public" est "neuve" (avec tous les rechargements
mémoire/sgbdr que ça implique en plus du ping-pong totalement inutile). Si
tu peux/veux exécuter un script par require local, il y a potentiellement
quelques adaptations : une constante ne peut pas être redéfinie, et
require_once( ) pour éviter les définitions multiples de fonctions. Là
c'est de l'organisation de code, pas plus.

JG

Sur le fond, oui, c'est (aussi) une bonne manière de faire. Après si tu
fais un reset des données mémoire locale au script par un header location
(qui implique un ping pong http) tu ne te poses pas de questions car toute
exécution de script "public" est "neuve" (avec tous les rechargements
mémoire/sgbdr que ça implique en plus du ping-pong totalement inutile). Si
tu peux/veux exécuter un script par require local, il y a potentiellement
quelques adaptations : une constante ne peut pas être redéfinie, et
require_once( ) pour éviter les définitions multiples de fonctions. Là
c'est de l'organisation de code, pas plus.

Me voilà un peut rassuré.
Je n'avais pas pensé à require_once() (quel imbécile !) ça reglerais une
bonne partie du problème, mais au niveau des constantes, la seule
manière de gérer le problème serait de les remplacer par des
variables... et je ne suis pas super chaud pour déclarer les droits
d'exécutions dans des variable, surtout dans un script qui passe son
temps à faire des includes, car je me retrouverais avec un gros risque
de redéfinission par l'utilisateur qui pourais faire correspondre les
droits requis avec les droits qu'il a...