Utiliser un formulaire en mode consultation uniquement
19 réponses
Alain BARTHE
Bonjour,
J'aimerais savoir s'il existe un moyen simple pour utiliser un
formulaire HTML en mode consultation.
Dans le détail :
- j'ai décrit dans un fichier JSON (peut-être plus tard YAML) les
caractéristiques des champs des tables de ma base SQL
- pour chaque champ d'une base, je spécifie un label à afficher, le type
de champ (TEXT, TEXTAREA, RADIO, CHECKBOX, ...), quelques attributs
(SIZE, NAME,...)
- à partir de ce fichier descriptif, je génère un formulaire HTML
classique <FORM> ... </FORM>, contenant des rubriques <INPUT>,
<TEXTAREA>,...
Ca fonctionne correctement, mais on me demande maintenant d'ajouter une
rubrique permettant d'afficher uniquement les données, sans pouvoir les
modifier.
J'aurais aimé réutiliser le plus possible le code qui génère le
formulaire de saisie, pour générer un "formulaire d'affichage".
Y a-t-il moyen de modifier au minimum un formulaire pour qu'il ne soit
pas possible de modifier les champs, mais juste de les afficher ?
J'aimerais savoir s'il existe un moyen simple pour utiliser un formulaire HTML en mode consultation.
(snip) >
Tu as l'air désolé.
??? Où ça ?
C'est moi qui ait mal compris le <snip>....
Je suis vraiment trop nul en Anglais.
Alain BARTHE
Alain BARTHE a écrit :
Merci à tous les quatre.
J'ai testé les attributs readonly et disabled, ils fonctionnent parfaitement. - readonly : on peut cliquer sur les zones mais pas les modifier - disabled : on ne peut même pas cliquer sur la zone (je préfère)
J'ai pu modifier mon générateur de formulaire en ajoutant juste :
if ($mode == "consultation") $field ["attr"]["disabled"] = "disabled";
Dernier souci, les attributs "disabled" font que je champs ne sont pas envoyés dans le POST.
Confert la doc cité par Bruno dans un mail précédent : http://www.w3.org/TR/html401/interact/forms.html#adef-disabled
C'est dommage, car leur comportement m'allait tellement bien dans le formlaire de consultation, que j'en avais mis dans certains champs du formulaire classique (notamment les ID (cles) de mes tables pour empécher leut modification).
Manque de pot, quand je veux re-enregistrer un fiche apres modification, la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me rajoute une deuxième fiche, avec un ID auto-incrementé
Le même problème ne se pose pas avec l'attribut "readonly", mais leur comportement coorespond moins à ce que je voulais.
Si vous connaissez une solution, tant mieux, sinon je reviendrai en arrière dans mon formulaire classique.
Merci encore pour votre aide à tous.
Alain BARTHE a écrit :
Merci à tous les quatre.
J'ai testé les attributs readonly et disabled, ils fonctionnent
parfaitement.
- readonly : on peut cliquer sur les zones mais pas les modifier
- disabled : on ne peut même pas cliquer sur la zone (je préfère)
J'ai pu modifier mon générateur de formulaire en ajoutant juste :
if ($mode == "consultation")
$field ["attr"]["disabled"] = "disabled";
Dernier souci, les attributs "disabled" font que je champs ne sont pas
envoyés dans le POST.
Confert la doc cité par Bruno dans un mail précédent :
http://www.w3.org/TR/html401/interact/forms.html#adef-disabled
C'est dommage, car leur comportement m'allait tellement bien dans le
formlaire de consultation, que j'en avais mis dans certains champs du
formulaire classique (notamment les ID (cles) de mes tables pour
empécher leut modification).
Manque de pot, quand je veux re-enregistrer un fiche apres modification,
la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me
rajoute une deuxième fiche, avec un ID auto-incrementé
Le même problème ne se pose pas avec l'attribut "readonly", mais leur
comportement coorespond moins à ce que je voulais.
Si vous connaissez une solution, tant mieux, sinon je reviendrai en
arrière dans mon formulaire classique.
J'ai testé les attributs readonly et disabled, ils fonctionnent parfaitement. - readonly : on peut cliquer sur les zones mais pas les modifier - disabled : on ne peut même pas cliquer sur la zone (je préfère)
J'ai pu modifier mon générateur de formulaire en ajoutant juste :
if ($mode == "consultation") $field ["attr"]["disabled"] = "disabled";
Dernier souci, les attributs "disabled" font que je champs ne sont pas envoyés dans le POST.
Confert la doc cité par Bruno dans un mail précédent : http://www.w3.org/TR/html401/interact/forms.html#adef-disabled
C'est dommage, car leur comportement m'allait tellement bien dans le formlaire de consultation, que j'en avais mis dans certains champs du formulaire classique (notamment les ID (cles) de mes tables pour empécher leut modification).
Manque de pot, quand je veux re-enregistrer un fiche apres modification, la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me rajoute une deuxième fiche, avec un ID auto-incrementé
Le même problème ne se pose pas avec l'attribut "readonly", mais leur comportement coorespond moins à ce que je voulais.
Si vous connaissez une solution, tant mieux, sinon je reviendrai en arrière dans mon formulaire classique.
Merci encore pour votre aide à tous.
Mickael Wolff
Le 06/05/2010 00:52, Alain BARTHE a écrit :
Dernier souci, les attributs "disabled" font que je champs ne sont pas envoyés dans le POST.
En quoi c'est un soucis ? C'était bien le résultat attendu.
C'est dommage, car leur comportement m'allait tellement bien dans le formlaire de consultation, que j'en avais mis dans certains champs du formulaire classique (notamment les ID (cles) de mes tables pour empécher leut modification).
Comme je l'avais précisé dans ma réponse, c'est du cosmétique. Le contrôle de l'ajout ou de la modification *doit* se faire du côté du serveur.
Manque de pot, quand je veux re-enregistrer un fiche apres modification, la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me rajoute une deuxième fiche, avec un ID auto-incrementé
Tu as un problème de design. Si les utilisateurs peuvent soumettre des données alors qu'ils ne l'ont pas requis, que des données s'ajoutent alors qu'elles existent déjà en base, c'est qu'il y a un problème.
Une première solution consiste à introduire un champ caché nommé « action » par exemple, et auquel tu affecte la valeur 'edit' ou 'view' selon le contexte. Ensuite tu peux améliorer le système en utilisant la technique dites des « token », qui associe à un formulaire un identifiant unique. Cette technique permet d'associer un contexte à la transaction.
Ceci dit, ça ne résout pas le problème de gestion des droits. -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org
Le 06/05/2010 00:52, Alain BARTHE a écrit :
Dernier souci, les attributs "disabled" font que je champs ne sont pas
envoyés dans le POST.
En quoi c'est un soucis ? C'était bien le résultat attendu.
C'est dommage, car leur comportement m'allait tellement bien dans le
formlaire de consultation, que j'en avais mis dans certains champs du
formulaire classique (notamment les ID (cles) de mes tables pour
empécher leut modification).
Comme je l'avais précisé dans ma réponse, c'est du cosmétique. Le
contrôle de l'ajout ou de la modification *doit* se faire du côté du
serveur.
Manque de pot, quand je veux re-enregistrer un fiche apres modification,
la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me
rajoute une deuxième fiche, avec un ID auto-incrementé
Tu as un problème de design. Si les utilisateurs peuvent soumettre
des données alors qu'ils ne l'ont pas requis, que des données s'ajoutent
alors qu'elles existent déjà en base, c'est qu'il y a un problème.
Une première solution consiste à introduire un champ caché nommé «
action » par exemple, et auquel tu affecte la valeur 'edit' ou 'view'
selon le contexte. Ensuite tu peux améliorer le système en utilisant la
technique dites des « token », qui associe à un formulaire un
identifiant unique. Cette technique permet d'associer un contexte à la
transaction.
Ceci dit, ça ne résout pas le problème de gestion des droits.
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Dernier souci, les attributs "disabled" font que je champs ne sont pas envoyés dans le POST.
En quoi c'est un soucis ? C'était bien le résultat attendu.
C'est dommage, car leur comportement m'allait tellement bien dans le formlaire de consultation, que j'en avais mis dans certains champs du formulaire classique (notamment les ID (cles) de mes tables pour empécher leut modification).
Comme je l'avais précisé dans ma réponse, c'est du cosmétique. Le contrôle de l'ajout ou de la modification *doit* se faire du côté du serveur.
Manque de pot, quand je veux re-enregistrer un fiche apres modification, la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me rajoute une deuxième fiche, avec un ID auto-incrementé
Tu as un problème de design. Si les utilisateurs peuvent soumettre des données alors qu'ils ne l'ont pas requis, que des données s'ajoutent alors qu'elles existent déjà en base, c'est qu'il y a un problème.
Une première solution consiste à introduire un champ caché nommé « action » par exemple, et auquel tu affecte la valeur 'edit' ou 'view' selon le contexte. Ensuite tu peux améliorer le système en utilisant la technique dites des « token », qui associe à un formulaire un identifiant unique. Cette technique permet d'associer un contexte à la transaction.
Ceci dit, ça ne résout pas le problème de gestion des droits. -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org
Bruno Desthuilliers
Alain BARTHE a écrit :
Alain BARTHE a écrit :
Merci à tous les quatre.
J'ai testé les attributs readonly et disabled, ils fonctionnent parfaitement. - readonly : on peut cliquer sur les zones mais pas les modifier - disabled : on ne peut même pas cliquer sur la zone (je préfère)
J'ai pu modifier mon générateur de formulaire en ajoutant juste :
if ($mode == "consultation") $field ["attr"]["disabled"] = "disabled";
Dernier souci, les attributs "disabled" font que je champs ne sont pas envoyés dans le POST.
Confert la doc cité par Bruno dans un mail précédent : http://www.w3.org/TR/html401/interact/forms.html#adef-disabled
C'est dommage, car leur comportement m'allait tellement bien dans le formlaire de consultation, que j'en avais mis dans certains champs du formulaire classique (notamment les ID (cles) de mes tables pour empécher leut modification).
Manque de pot, quand je veux re-enregistrer un fiche apres modification, la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me rajoute une deuxième fiche, avec un ID auto-incrementé
Si tu veux vraiment afficher l'id, tu peux le mettre dans un champ texte disabled, avec un autre nom.
Alain BARTHE a écrit :
Alain BARTHE a écrit :
Merci à tous les quatre.
J'ai testé les attributs readonly et disabled, ils fonctionnent
parfaitement.
- readonly : on peut cliquer sur les zones mais pas les modifier
- disabled : on ne peut même pas cliquer sur la zone (je préfère)
J'ai pu modifier mon générateur de formulaire en ajoutant juste :
if ($mode == "consultation")
$field ["attr"]["disabled"] = "disabled";
Dernier souci, les attributs "disabled" font que je champs ne sont pas
envoyés dans le POST.
Confert la doc cité par Bruno dans un mail précédent :
http://www.w3.org/TR/html401/interact/forms.html#adef-disabled
C'est dommage, car leur comportement m'allait tellement bien dans le
formlaire de consultation, que j'en avais mis dans certains champs du
formulaire classique (notamment les ID (cles) de mes tables pour
empécher leut modification).
Manque de pot, quand je veux re-enregistrer un fiche apres modification,
la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me
rajoute une deuxième fiche, avec un ID auto-incrementé
J'ai testé les attributs readonly et disabled, ils fonctionnent parfaitement. - readonly : on peut cliquer sur les zones mais pas les modifier - disabled : on ne peut même pas cliquer sur la zone (je préfère)
J'ai pu modifier mon générateur de formulaire en ajoutant juste :
if ($mode == "consultation") $field ["attr"]["disabled"] = "disabled";
Dernier souci, les attributs "disabled" font que je champs ne sont pas envoyés dans le POST.
Confert la doc cité par Bruno dans un mail précédent : http://www.w3.org/TR/html401/interact/forms.html#adef-disabled
C'est dommage, car leur comportement m'allait tellement bien dans le formlaire de consultation, que j'en avais mis dans certains champs du formulaire classique (notamment les ID (cles) de mes tables pour empécher leut modification).
Manque de pot, quand je veux re-enregistrer un fiche apres modification, la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me rajoute une deuxième fiche, avec un ID auto-incrementé
Si tu veux vraiment afficher l'id, tu peux le mettre dans un champ texte disabled, avec un autre nom.
Alain BARTHE
Mickael Wolff a écrit :
Le 06/05/2010 00:52, Alain BARTHE a écrit :
Dernier souci, les attributs "disabled" font que je champs ne sont pas envoyés dans le POST.
En quoi c'est un soucis ? C'était bien le résultat attendu.
Je voulais me servir de cet attribut pour afficher les valeurs dans ces champs, sans que l'utilisateur puisse sélectionner la zone ni la modifier, mais que ces valeurs soient transmises au POST quand je reenregistre ma fiche après modification.
Apparemment, cet attribut n'est pas prévu pour ça, ce serait plutôt le readonly que je devrais utiliser, mais il donne le focus sur la zone de saisie, tout en interdisant de la modifier.
Ca me dérange un peu, mais je pinaille.
C'est dommage, car leur comportement m'allait tellement bien dans le formlaire de consultation, que j'en avais mis dans certains champs du formulaire classique (notamment les ID (cles) de mes tables pour empécher leut modification).
Comme je l'avais précisé dans ma réponse, c'est du cosmétique. Le contrôle de l'ajout ou de la modification *doit* se faire du côté du serveur.
C'est bien ce que je fais : quand je crée une nouvelle fiche, j'initialise le champ ID du formulaire à NULL ou -1, sinon en modification, j'ai la valeur de l'ID > 0.
J'affichais auparavant cette valeur avec quelque chose comme : echo "<input name='id' type='hidden'>$ID</input>
J'ai voulu le remplacer par : echo "<input name='id' type='text' value=$ID disabled></input>"
Ca fonctionne correctement pour l'affichage, mais n'est pas envoyé dans le POST (avec readonly si, mais c'est moins joli)
Bref, je vais repartir sur ma solution initiale: dommange..
Manque de pot, quand je veux re-enregistrer un fiche apres modification, la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me rajoute une deuxième fiche, avec un ID auto-incrementé
Tu as un problème de design. Si les utilisateurs peuvent soumettre des données alors qu'ils ne l'ont pas requis, que des données s'ajoutent alors qu'elles existent déjà en base, c'est qu'il y a un problème.
Une première solution consiste à introduire un champ caché nommé « action » par exemple, et auquel tu affecte la valeur 'edit' ou 'view' selon le contexte. Ensuite tu peux améliorer le système en utilisant la technique dites des « token », qui associe à un formulaire un identifiant unique. Cette technique permet d'associer un contexte à la transaction.
Je vais jeter un coup d'oeil de ce coté là.
Ceci dit, ça ne résout pas le problème de gestion des droits.
Je pense régler ça avec des autorisations Apache (dans .htaccess probablement), avec des autorisations différentes pour les scripts de consultation et de modification (qui utilisent tous deux le même formulaire).
En consultation, je n'ai pas de problème : je mets tous les champs avec l'attribut disabled et je n'ai pas de problème de POST puisque je n'enregistre rien.
Merci encore pour vos conseils.
Mickael Wolff a écrit :
Le 06/05/2010 00:52, Alain BARTHE a écrit :
Dernier souci, les attributs "disabled" font que je champs ne sont pas
envoyés dans le POST.
En quoi c'est un soucis ? C'était bien le résultat attendu.
Je voulais me servir de cet attribut pour afficher les valeurs dans ces
champs, sans que l'utilisateur puisse sélectionner la zone ni la
modifier, mais que ces valeurs soient transmises au POST quand je
reenregistre ma fiche après modification.
Apparemment, cet attribut n'est pas prévu pour ça, ce serait plutôt le
readonly que je devrais utiliser, mais il donne le focus sur la zone de
saisie, tout en interdisant de la modifier.
Ca me dérange un peu, mais je pinaille.
C'est dommage, car leur comportement m'allait tellement bien dans le
formlaire de consultation, que j'en avais mis dans certains champs du
formulaire classique (notamment les ID (cles) de mes tables pour
empécher leut modification).
Comme je l'avais précisé dans ma réponse, c'est du cosmétique. Le
contrôle de l'ajout ou de la modification *doit* se faire du côté du
serveur.
C'est bien ce que je fais : quand je crée une nouvelle fiche,
j'initialise le champ ID du formulaire à NULL ou -1, sinon en
modification, j'ai la valeur de l'ID > 0.
J'affichais auparavant cette valeur avec quelque chose comme :
echo "<input name='id' type='hidden'>$ID</input>
J'ai voulu le remplacer par :
echo "<input name='id' type='text' value=$ID disabled></input>"
Ca fonctionne correctement pour l'affichage, mais n'est pas envoyé dans
le POST (avec readonly si, mais c'est moins joli)
Bref, je vais repartir sur ma solution initiale: dommange..
Manque de pot, quand je veux re-enregistrer un fiche apres modification,
la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me
rajoute une deuxième fiche, avec un ID auto-incrementé
Tu as un problème de design. Si les utilisateurs peuvent soumettre des
données alors qu'ils ne l'ont pas requis, que des données s'ajoutent
alors qu'elles existent déjà en base, c'est qu'il y a un problème.
Une première solution consiste à introduire un champ caché nommé «
action » par exemple, et auquel tu affecte la valeur 'edit' ou 'view'
selon le contexte. Ensuite tu peux améliorer le système en utilisant la
technique dites des « token », qui associe à un formulaire un
identifiant unique. Cette technique permet d'associer un contexte à la
transaction.
Je vais jeter un coup d'oeil de ce coté là.
Ceci dit, ça ne résout pas le problème de gestion des droits.
Je pense régler ça avec des autorisations Apache (dans .htaccess
probablement), avec des autorisations différentes pour les scripts de
consultation et de modification (qui utilisent tous deux le même
formulaire).
En consultation, je n'ai pas de problème : je mets tous les champs avec
l'attribut disabled et je n'ai pas de problème de POST puisque je
n'enregistre rien.
Dernier souci, les attributs "disabled" font que je champs ne sont pas envoyés dans le POST.
En quoi c'est un soucis ? C'était bien le résultat attendu.
Je voulais me servir de cet attribut pour afficher les valeurs dans ces champs, sans que l'utilisateur puisse sélectionner la zone ni la modifier, mais que ces valeurs soient transmises au POST quand je reenregistre ma fiche après modification.
Apparemment, cet attribut n'est pas prévu pour ça, ce serait plutôt le readonly que je devrais utiliser, mais il donne le focus sur la zone de saisie, tout en interdisant de la modifier.
Ca me dérange un peu, mais je pinaille.
C'est dommage, car leur comportement m'allait tellement bien dans le formlaire de consultation, que j'en avais mis dans certains champs du formulaire classique (notamment les ID (cles) de mes tables pour empécher leut modification).
Comme je l'avais précisé dans ma réponse, c'est du cosmétique. Le contrôle de l'ajout ou de la modification *doit* se faire du côté du serveur.
C'est bien ce que je fais : quand je crée une nouvelle fiche, j'initialise le champ ID du formulaire à NULL ou -1, sinon en modification, j'ai la valeur de l'ID > 0.
J'affichais auparavant cette valeur avec quelque chose comme : echo "<input name='id' type='hidden'>$ID</input>
J'ai voulu le remplacer par : echo "<input name='id' type='text' value=$ID disabled></input>"
Ca fonctionne correctement pour l'affichage, mais n'est pas envoyé dans le POST (avec readonly si, mais c'est moins joli)
Bref, je vais repartir sur ma solution initiale: dommange..
Manque de pot, quand je veux re-enregistrer un fiche apres modification, la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me rajoute une deuxième fiche, avec un ID auto-incrementé
Tu as un problème de design. Si les utilisateurs peuvent soumettre des données alors qu'ils ne l'ont pas requis, que des données s'ajoutent alors qu'elles existent déjà en base, c'est qu'il y a un problème.
Une première solution consiste à introduire un champ caché nommé « action » par exemple, et auquel tu affecte la valeur 'edit' ou 'view' selon le contexte. Ensuite tu peux améliorer le système en utilisant la technique dites des « token », qui associe à un formulaire un identifiant unique. Cette technique permet d'associer un contexte à la transaction.
Je vais jeter un coup d'oeil de ce coté là.
Ceci dit, ça ne résout pas le problème de gestion des droits.
Je pense régler ça avec des autorisations Apache (dans .htaccess probablement), avec des autorisations différentes pour les scripts de consultation et de modification (qui utilisent tous deux le même formulaire).
En consultation, je n'ai pas de problème : je mets tous les champs avec l'attribut disabled et je n'ai pas de problème de POST puisque je n'enregistre rien.
Si tu veux vraiment afficher l'id, tu peux le mettre dans un champ texte disabled, avec un autre nom.
C'est exactement ce que je faisais auparavant, mais j'avais trouvé que l'attribut disabled était très pratique.
Il suffisait de le rajouter pour afficher les valeurs des champs non modifiables, tout en bloquant la saisie, et même le focus pour les utilisateurs.
Seul problème, ils ne sont pas transmis au POST quand je veux enregistrer la fiche. Dommage...
L'attribut readonly fait que les valeurs sont transmises, mais l'utilisateur peut cliquer sur la zone de saisie.
Seule la saisie est interdite. Avec les dégourdis que j'ai, ils vont croire que leur clavier est en panne!!!
Bref, je pinaille... Je vais repartir sur ma solution initiale et clore le sujet.
Merci encore.
Mickael Wolff
Le 06/05/2010 12:17, Alain BARTHE a écrit :
C'est bien ce que je fais : quand je crée une nouvelle fiche, j'initialise le champ ID du formulaire à NULL ou -1, sinon en modification, j'ai la valeur de l'ID > 0.
C'est moche. Je sais que ça se fait beaucoup, mais pour le déboguage, ça risque de te pénaliser. C'est le problème des astuces, au début on se dit que c'est super intelligent. Et finalement, ben c'est pas génial.
Je pense régler ça avec des autorisations Apache (dans .htaccess probablement), avec des autorisations différentes pour les scripts de consultation et de modification (qui utilisent tous deux le même formulaire).
Non /o Le .htaccess ne suffira pas. Fais une recherche Google à propos de CSRF et de la technique des tokens.
C'est bien ce que je fais : quand je crée une nouvelle fiche,
j'initialise le champ ID du formulaire à NULL ou -1, sinon en
modification, j'ai la valeur de l'ID > 0.
C'est moche. Je sais que ça se fait beaucoup, mais pour le déboguage,
ça risque de te pénaliser. C'est le problème des astuces, au début on se
dit que c'est super intelligent. Et finalement, ben c'est pas génial.
Je pense régler ça avec des autorisations Apache (dans .htaccess
probablement), avec des autorisations différentes pour les scripts de
consultation et de modification (qui utilisent tous deux le même
formulaire).
Non /o
Le .htaccess ne suffira pas. Fais une recherche Google à propos de
CSRF et de la technique des tokens.
C'est bien ce que je fais : quand je crée une nouvelle fiche, j'initialise le champ ID du formulaire à NULL ou -1, sinon en modification, j'ai la valeur de l'ID > 0.
C'est moche. Je sais que ça se fait beaucoup, mais pour le déboguage, ça risque de te pénaliser. C'est le problème des astuces, au début on se dit que c'est super intelligent. Et finalement, ben c'est pas génial.
Je pense régler ça avec des autorisations Apache (dans .htaccess probablement), avec des autorisations différentes pour les scripts de consultation et de modification (qui utilisent tous deux le même formulaire).
Non /o Le .htaccess ne suffira pas. Fais une recherche Google à propos de CSRF et de la technique des tokens.
Je pense régler ça avec des autorisations Apache (dans .htaccess probablement), avec des autorisations différentes pour les scripts de consultation et de modification (qui utilisent tous deux le même formulaire).
Non /o Le .htaccess ne suffira pas. Fais une recherche Google à propos de CSRF et de la technique des tokens.
Je débute en PHP comme en MySQL et c'est vrai que je ne me suis pas trop penché sur la sécurité.
Dans ce cas, ce n'est pas une application critique : juste une appli en intranet utilisée par 2/3 personnes, qui me permet de me faire la main pour plus tard.
J'avais commencé à lire un papier sur la sécurisation des données des formulaires, pour éviter les attaques par injection de code. Intéressant...
Il faudra que j'intègre ces techniques, petit à petit. Ca fait beaucoup de trucs à assimiler dans un premier temps.
Je suis d'accord avec toi pour dire que ça devient indispensable.
Merci beaucoup pour tous ces conseil (et votre patience!!!)
Mickael Wolff a écrit :
Je pense régler ça avec des autorisations Apache (dans .htaccess
probablement), avec des autorisations différentes pour les scripts de
consultation et de modification (qui utilisent tous deux le même
formulaire).
Non /o
Le .htaccess ne suffira pas. Fais une recherche Google à propos de
CSRF et de la technique des tokens.
Je débute en PHP comme en MySQL et c'est vrai que je ne me suis pas trop
penché sur la sécurité.
Dans ce cas, ce n'est pas une application critique : juste une appli en
intranet utilisée par 2/3 personnes, qui me permet de me faire la main
pour plus tard.
J'avais commencé à lire un papier sur la sécurisation des données des
formulaires, pour éviter les attaques par injection de code. Intéressant...
Il faudra que j'intègre ces techniques, petit à petit.
Ca fait beaucoup de trucs à assimiler dans un premier temps.
Je suis d'accord avec toi pour dire que ça devient indispensable.
Merci beaucoup pour tous ces conseil (et votre patience!!!)
Je pense régler ça avec des autorisations Apache (dans .htaccess probablement), avec des autorisations différentes pour les scripts de consultation et de modification (qui utilisent tous deux le même formulaire).
Non /o Le .htaccess ne suffira pas. Fais une recherche Google à propos de CSRF et de la technique des tokens.
Je débute en PHP comme en MySQL et c'est vrai que je ne me suis pas trop penché sur la sécurité.
Dans ce cas, ce n'est pas une application critique : juste une appli en intranet utilisée par 2/3 personnes, qui me permet de me faire la main pour plus tard.
J'avais commencé à lire un papier sur la sécurisation des données des formulaires, pour éviter les attaques par injection de code. Intéressant...
Il faudra que j'intègre ces techniques, petit à petit. Ca fait beaucoup de trucs à assimiler dans un premier temps.
Je suis d'accord avec toi pour dire que ça devient indispensable.
Merci beaucoup pour tous ces conseil (et votre patience!!!)
John GALLET
Bonjour,
Manque de pot, quand je veux re-enregistrer un fiche apres modification, la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me rajoute une deuxième fiche, avec un ID auto-incrementé
Donc on a un problème d'absence clef unique/primaire correcte, ce sera la même chose avec un refresh...
Pour ce point là, on peut le faire passer en hidden, mais attention aux problèmes de droit d'accès (si l'utilisateur X n'a pas le droit de modifier l'identifiant 1234, il lui suffit d'éditer le html et de mettre ce qu'il veut dedans, il faut revérifier c$oté serveur).
Si vous connaissez une solution,
Ton besoin est vraiment ici de NE PAS faire transiter les données, pas de les faire transiter en espérant qu'on ne les modifiera pas (ce qui n'empêche en rien de les afficher dans des formulaires en readonly, par exemple pour faire une interface de traduction, on aime bien pouvoir copier-coller le texte d'origine pour le traduire).
C'est *exactement* à ça que servent les *sessions*: conserver les données côté *serveur*.
a++; JGA
Bonjour,
Manque de pot, quand je veux re-enregistrer un fiche apres modification,
la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me
rajoute une deuxième fiche, avec un ID auto-incrementé
Donc on a un problème d'absence clef unique/primaire correcte, ce sera
la même chose avec un refresh...
Pour ce point là, on peut le faire passer en hidden, mais attention aux
problèmes de droit d'accès (si l'utilisateur X n'a pas le droit de
modifier l'identifiant 1234, il lui suffit d'éditer le html et de mettre
ce qu'il veut dedans, il faut revérifier c$oté serveur).
Si vous connaissez une solution,
Ton besoin est vraiment ici de NE PAS faire transiter les données, pas
de les faire transiter en espérant qu'on ne les modifiera pas (ce qui
n'empêche en rien de les afficher dans des formulaires en readonly, par
exemple pour faire une interface de traduction, on aime bien pouvoir
copier-coller le texte d'origine pour le traduire).
C'est *exactement* à ça que servent les *sessions*: conserver les
données côté *serveur*.
Manque de pot, quand je veux re-enregistrer un fiche apres modification, la variable $_POST["id"] n'est pas transmise, ce qu'il fait qu'il me rajoute une deuxième fiche, avec un ID auto-incrementé
Donc on a un problème d'absence clef unique/primaire correcte, ce sera la même chose avec un refresh...
Pour ce point là, on peut le faire passer en hidden, mais attention aux problèmes de droit d'accès (si l'utilisateur X n'a pas le droit de modifier l'identifiant 1234, il lui suffit d'éditer le html et de mettre ce qu'il veut dedans, il faut revérifier c$oté serveur).
Si vous connaissez une solution,
Ton besoin est vraiment ici de NE PAS faire transiter les données, pas de les faire transiter en espérant qu'on ne les modifiera pas (ce qui n'empêche en rien de les afficher dans des formulaires en readonly, par exemple pour faire une interface de traduction, on aime bien pouvoir copier-coller le texte d'origine pour le traduire).
C'est *exactement* à ça que servent les *sessions*: conserver les données côté *serveur*.
