mon code de requête PHP et mon code formulaire HTML pour envoyer des données à la requête supérieure p> MAINTENANT que vous connaissez les champs cachés Peut modifier pour inspecter la source dans les navigateurs Web par tout le corps, comment puis-je envoyer des données sous forme de requête dans la même page sans aucun champ d'entrée comme Hiddens?
Comment utiliser des variables au lieu des champs masqués d'entrée? P> merci p> p> p>
5 Réponses :
Vous pouvez utiliser la session pour ces champs ..
Nul besoin de prendre des champs cachés. P>
Vous pouvez utiliser directement des variables de session. P>
<?php if (isset($_POST['btn_add'])) { $query_insert = "INSERT INTO Calc_Tbl(id_Customer,Flname_Customer) VALUES ('".$_SESSION["id"]."','".$_SESSION["flname"]."')"; mysqli_query($db, $query_insert); } ?>
Je l'ai utilisé avant mais je n'ai pas travaillé. S'il vous plaît, veuillez me dire un exemple dans la même page par sessions. Merci beaucoup.
Le formulaire doit être comme celui-ci:
@AriaShir: Les valeurs de session n'ont rien à voir avec le formulaire HTML. Si vous souhaitez utiliser une session dans ce cas i> (vous ne devriez pas, mais vous semblez vouloir vouloir), vous définissez vos valeurs de session dans le code côté serveur lorsque la page se charge. Ensuite, lorsque l'utilisateur soumet le formulaire, vous allez lire ces valeurs de session à utiliser dans votre requête. (Cela sera compliqué très rapidement si vous avez une page avec plusieurs enregistrements, tels qu'un tableau d'enregistrements avec des boutons "Supprimer". Ou si les utilisateurs commencent à naviguer autour du site de manière inattendue, ce qu'ils font souvent.)
Voir p>
Vous pouvez chiffrer ces données et le valider sur le côté serveur, comme il est dit dans l'une des réponses de cette question, va p>
Comme il a été dit dans ce lien dans certaines des réponses, vous pouvez chiffrer les champs cachés d'une manière ou d'une autre. p>
Mettez vos données variables en variables globales $ _session. reste de votre formulaire code HTML restera telle qu'elle est p>
Le programme PHP où votre formulaire est si un autre champ a été soumis, ils seront à l'intérieur $ _POST , naturellement de
Pour cette première chose à faire, c'est de commencer vos sessions comme celle-ci posté code> pour commencer par p>
Jusqu'à ce que $ _Session soit détruit à l'aide de session_destroy;, vos variables seront trouvées dans tout autre programme que vous utilisez ultérieurement. p> p>
salut merci. J'ai d'autres sessions si j'utilise session_destroy (); D'autres sessions vont également détruire. Comment l'empêcher?
@AriaShir: Cela ressemble à un problème différent et non liée. session_destroy () code> ne détruit que la session en cours, il n'a aucun effet sur les sessions d'autres utilisateurs pouvant être ouvertes simultanément. Si vous observez autrement, cela ressemble à un problème dans la gestion des données de la session.
@David, j'ai utilisé session_destroy (); Après avoir terminé la requête, puis la page chargée et toutes les sons détruits. : /
@AriaShir: Ensuite, vous le décrivez de manière incorrecte ou autre chose, à l'extérieur du code / de la fonctionnalité indiquée, est fausse. Quoi qu'il en soit, en utilisant des sessions pour cela est essentiellement une mauvaise idée et surcharge des questions. Il peut travailler i>, afin que les réponses recommandent qu'il soit valide à part entière. Mais vous ferez probablement mieux de simplement valider les données soumises plutôt que d'essayer de suivre toutes les données du serveur de données. La gestion de l'État est difficile et dans ce cas, il est également inutile.
@AriaShir: Si vous souhaitez détruire une variable de session spécifique, vous pouvez utiliser comme nonset ($ _ session ["id ']); code>
non défini ($ _ session'flname'); code> - Cela ne fera que des variables seulement que vous souhaitez supprimer de $ _Session. session_destroy (); va tout supprimer de $ _session.
With Ajax you can do like this : var first = 'data1'; var second = 'data2'; $("body").off("submit","#assignedUserForm").on("submit","#assignedUserForm",function(){ $("#assignedUserForm [type='submit']").text('Loading...').prop('disabled', true); $('<input>').attr({ type: 'hidden', name: 'id_Hidden', value: first }).appendTo('#assignedUserForm'); $('<input>').attr({ type: 'hidden', name: 'flname_Hidden', value: second }).appendTo('#assignedUserForm'); var formData = new FormData(this); $.ajax({ url: 'url.php', type: 'POST', data: formData, contentType: false, cache: false, processData: false, success: function (response) { $("#assignedUserForm [type='submit']").text('Submit').prop('disabled', false); } }); return false; });
Comment cela répond-il à la préoccupation des utilisateurs pouvant soumettre des données non valides?
votre doit définir à JQuery en tant que variable globale que je vais le modifier
Les utilisateurs peuvent toujours soumettre toutes les valeurs qu'ils aiment à l'API dans ce cas. Ajax n'est pas une baguette magique et JQuery n'est pas une baguette magique. Dans votre code, le serveur s'appuie toujours sur des valeurs du client et suppose toujours que ces valeurs sont correctes.
que vous devez ajouter les en-têtes HTTP de votre extrémité, il convient de provoquer le même domaine d'autre que vous pouvez générer un jeton, puis valider à votre extrémité.
Vous regardez le problème de la mauvaise perspective. Le problème n'est pas que l'utilisateur puisse soumettre des valeurs incorrectes. strong> Le problème est que votre code côté serveur suppose em> que les valeurs sont correctes. Les champs cachés peuvent modifier la source d'inspecter dans des navigateurs Web par chaque corps p>
BlockQuote> Oui, c'est vrai. Les utilisateurs peuvent également fabriquer toute demande de votre serveur entièrement en dehors d'un navigateur Web. Il est fondamentalement vrai que tout client peut envoyer n'importe quelle demande à votre serveur à tout moment. P> plutôt que d'essayer de le combattre, il suffit de vous en tenir compte. Demandez-vous ... P> Pourquoi l'utilisateur doit-il pas être autorisé à soumettre une valeur Y dans ce champ? P>
BlockQuote> Par exemple, peut-être que cette valeur / enregistrement appartient à un utilisateur différent et que cet utilisateur ne doit pas être en mesure de modifier les enregistrements des autres utilisateurs. Ensuite, c'est exactement ce que vous devriez valider le côté serveur. P> exprimé en pseudo-code: p> donc alors qu'est-ce que Veuillez noter que ce qui précède est pseudo-code em> et vous ne pourrez pas simplement copier / coller le tel. Pour travailler. Mais j'espère qu'il illustre le point général. Pour le dire simplement: P> Lorsqu'un utilisateur tente d'effectuer une action, déterminez d'abord si l'utilisateur est autorisé em> d'effectuer cette action. S'ils ne le sont pas, renvoyez une erreur. S'ils sont, effectuez l'action. P>
blockQuote> C'est vraiment tout ce qu'il y a. Ne faites jamais implicitement confiance aux informations du client. Validez toujours que l'utilisateur est autorisé à faire ce qu'ils essaient de faire. P> Note latérale, à la suite de tous les autres conseils publiés dans cette question / réponses jusqu'à présent ... P > Les sessions sont Il n'y a absolument rien de mal avec le client fournissant des valeurs "cachées" que le serveur utilise. En effet, cela permet à vos services d'être beaucoup plus reposant et beaucoup plus simple à utiliser et à entretenir. Tout ce que vous avez à faire est valider em> ces valeurs côté serveur avant d'y utiliser. P> p>
actuelUtiliser code>? Cela dépend de la manière dont vous suivez qui est l'utilisateur actuel. (Non inclus dans la question.) Cependant, vous suivez vos utilisateurs connectés, reportez-vous à cette information. Et qu'est-ce que
canedit () code>? Cela dépend de la manière dont vous déterminez si un utilisateur donné est autorisé à modifier un enregistrement donné. Vous devrez écrire cette logique. P>
Supposons qu'un client achète quelque chose puis dans la page de commande qu'il / elle doit sélectionner le nombre de ces produits. Donc, la multiplication du nombre sélectionné comptez sur le prix et stockez la somme des calculs calculés au champ caché (maintenant avec des sessions, c'est sûr), puis je stocke le prix SOMME du champ caché à la base de données.
@AriaShir: (1) Vous n'avez pas besoin de soumettre des valeurs calculées sur le formulaire. Calculez-les simplement lorsque vous en avez besoin. Lorsqu'une commande est soumise, vous recevez le produit sélectionné et Quaniy du client et vous connaissez le prix sur le serveur. L'arithmétique de base sur le serveur vous fournira le prix total. Vous pouvez stocker le total dans la base de données avec la commande car les prix peuvent changer, mais il peut être plus logique de stocker le prix à l'époque et d'effectuer toujours des calculs en cas de besoin. (2) Qu'est-ce que l'un de cela a à voir avec la question posée?
Peut-être a-t-il ajouté qu'un produit au panier et une autre journée peut ajouter à nouveau d'autres, alors il ouvre la page de panier et modifier le nombre de chaque produits distincts des autres et dans mon chiffre caché, la somme changera à chaque fois que tout compte de produit. :) et peut soumettre s'il veut
@Ariashir: À ce stade, on dirait que vous essayez de demander "Comment construire un panier?", Qui est beaucoup trop large pour une question de dépassement de pile (sans parler d'un commentaire). Si vous avez une question à poser, vous êtes encouragé à le demander.
C'est mon projet et je suis excitant de le faire et d'l'améliorer et d'apprendre étape par étape dans ce projet ... Je viens de rencontrer un problème dans cette question
inspecter la source code> n'est pas le seul moyen de manipuler des données. Un
CURL code> pourrait être utilisé aussi bien. Ce SQL est ouvert aux injections. Paramétrage. Je ne sais pas non plus ce que le principal
n code> s est.
Votre code est Large ouvert sur i> à Injection SQL B>. Vous devriez commencer à lire ici: PHP.net/manual/fr/ Security.Database.sql-injection.php et ici: Stackoverflow.com/Questtions/60174/...
En ce qui concerne la question posée, si vous souhaitez supprimer les champs code> puis allez-y et simplement les supprimer. Mais vous n'avez besoin de ne pas compter sur eux dans votre code SQL ou d'obtenir ces valeurs d'ailleurs. Où voudriez-vous suivre ces valeurs? Pourquoi les utilisateurs ne devraient-ils pas être capables d'insérer différentes valeurs en premier lieu? Si les utilisateurs ne sont pas autorisés à effectuer une action, vérifiez votre code côté serveur pour cette autorisation et n'effectuez pas cette action.
A User3783243 et @David /, exactement je ne comprends pas ce que vous voulez dire? Pourquoi mon code s'ouvre à l'injection SQL ?? S'il vous plaît donnez-moi plus d'informations sur.Qu'est-ce que tu veux dire? je t'aime
@Ariashir: "S'il vous plaît, donnez-moi plus d'informations" i> - veuillez vous reporter aux informations que vous avez déjà données. (Cliquez sur les liens que j'ai fournis dans mon premier commentaire ci-dessus.)
@David Vous voulez dire que la requête SQL peut être modifiée par chaque corps comme peut ajouter une table de goutte? Oui? mais comment? Les codes PHP n'ont jamais vu par les utilisateurs !!!!!
@AriaShir: L'injection SQL n'a rien à voir avec un utilisateur de pouvoir voir votre code PHP. L'injection SQL se produit car vous exécutez la saisie de l'utilisateur comme s'il s'agissait d'un code et tout simplement de confiance que l'entrée est probablement une valeur valide. Ce n'est peut-être pas une valeur, cela pourrait être un code SQL. Vous êtes à nouveau encouragé à suivre les liens qui vous ont été fournis et lire i> sur le sujet B>. Ils contiennent des exemples de l'injection SQL et de la façon de l'empêcher.
Merci cher David je lis votre lien et je l'ai eu ce que vous dites, vous dites que je dois ne pas utiliser comme ce code: (n '$ _ post [id_hiddori]') ??! Alors, comment définir des valeurs? S'il vous plaît répondez ici, je veux savoir ce que vous faites dans votre code et que dois-je faire.