Reprise du message précédent :

tu peux vérifier toi-même d'où vient ton utilisateur, mais par défaut ya pas de vérif de ce genre automatique...

comment ca le serait ?
 
tu peux essayer, copie un de tes formulaire en local, ouvre le, tape des trucs et valide.

Aucune vérification. Quand tu fais un form, l'attribut action il pointe où tu veux, ça peut être une URL absolue autre que ton site.
Heureusement d'ailleurs.
Ce qui est interdit en revanche c'est de faire de l'ajax cross-domain.
Y a des solutions pour contourner au cas où t'en ai besoin par contre.

Non, tu fais ce que tu veux à ce niveau (d'ailleurs pourquoi tu pourrais pas?)

ben y'a des trucs qui sont vérifés dans les browsers, j'pensais que l'origine du post et sa destination devaient correspondre.

non
 
c'est d'ailleurs ce qui permt simplement de faire des trucs droles avec les formulaire ne post mal protégés

'tain ça me paraît dingue.

pourquoi on permettrait pas à quelqu'un de faire une recherche google directement à-partir de son site, par exemple?

elle est en get la recherche, elle change pas l'état du système.

En quoi le fait qu'un formulaire soit en "get" ou en "post" change l'état du système?

POST est fait pour changer l'état du système, c'est le sens du verbe en HTTP.
 
GET, non.

Certe d'un point de vue théorique.
Mais en pratique, à part le fait qu'on ne récupère pas les données dans la même variable (ou pas au même endroit du flux si on récupère directement le flux) , je ne vois pas ce que ça change. En fait, en pratique, ce qui fait que le système "change d'état" n'est pas le fait qu'il reçoit des données en get ou en post mais ce qu'on fait des données reçu.

oui, c'est une convention.

 
Bon, alors on va poser la question autrement : comment tu veux que ce soit fait sans être contournable, ce genre de vérification? Le referer est considéré comme une info non fiable, car c'est une info envoyée par le navigateur...lequel peut choisir d'envoyer une connerie s'il veut.

La vérif serait faite par le navigateur (commen pour ajax et le cross domain)
Si t'es sur un site A et que tu es sur le point de soumettre en POST un form vers un site B, le navigateur te péterai une erreur

 
...et qui est-ce qui peut vérifier que ton navigateur respecte ça?
Tu peux très bien te faire un petit programme qui va POSTer ce que tu veux avec le referer de ton choix hein...

Le contenu de ce message a été effacé par son auteur

function fromPost($post, $files) {
                $this->num_set = $post['num_set'];
 
                for ($this->els = array(), $i = 0; $i < count($post['texte']); $i++) {

Elle est où la syntax error là (censée être à la deuxième ligne)

nan on se comprend mal. la question c'est que l'utilisateur ne clique pas sur un truc qui parte n'importe où. Par exemple, la lecture des cookies, ou la modification d'un DOM par du JS c'est très encadré dans un navigateur.

Parce que submit() ne nécéssite pas de bouton de submit ? (hypothèse)

mais non. Il s'agit que quand je vais visiter une page y'a pas cette page qui va me faire faire une connerie sur un autre site.

   
 
GET est fait pour poser une question au système, un GET est considéré comme idempotent (et ça fait partie des specs HTTP), il peut être caché, préfetché, etc...
 
POST, PUT, DELETE, ... sont faits pour modifier le système, ne doivent pas être cachés (que ce soit par le navigateur, par les proxy ou par quoi que ce soit d'autres), ne doivent pas être préfetchés, ...

Pas vraiment non. Par exemple, GET a le droit être caché, il est interdit de cacher un POST dans l'implémentation d'un proxy HTTP. De même, GET a le droit d'être préfetché, pas POST (vous vous souvenez déjà plus du Google Accelerator?)

je pense que les navigateurs recents permettent de controller le onload pour eviter ca, puisque c'est le seul vrai soucis.
 
pas de faire un post d'un domaine a l'autre, mais de le faire sans interraction utilisateur.

Le contenu de ce message a été effacé par son auteur

T'aurais pas oublié un return true dans ton handler de onsubmit, histoire de faire savoir au post qu'il a le droit de continuer?

1) ça empecherait pas mal de trucs pratiques
2) même si le navigateur l'empechait, il suffit de changer le REFERER et envoyer ce qu'on veut... La sécurité est pas terrible.

ouais, enfin un observateur de clic sur un lien aussi ça peut le faire.

mais changer le referer est une action volontaire, ça se fait pas en cliquant innocemment sur un lien "ici y'adu cul".
j'crois qu'on parle pas du même côté du tuyau.

Tu peux très bien envoyer ta requete en POST côté serveur (via un GET "ya du cul" ), c'est un poil plus compliqué menfin celui qui veut peut, c'est pas un pauvre navigateur qui va arrêter le Jérôme Kerviel qui sommeille en moi

Donc ce serait une sécu inefficace (celui qui veut faire mal peut quand même) et chiante (celui qui en a vraiment besoin est emmerdé)

mais non  

coté serveur, le vilain méchant ne connait pas la session de l'utilisateur, donc il peut tenter les POST qu'on veut, ca change rien.

comprend pas

function fromPost($post, $files) {
                $this->num_set = $post['num_set'];
 
                for ($this->els = array(), $i = 0; $i < count($post['texte']); $i++) {

Le contenu de ce message a été effacé par son auteur

function fromPost($post, $files) {
                $this->num_set = $post['num_set'];
 
                for ($this->els = array(), $i = 0; $i < count($post['texte']); $i++) {

for (truc ; truc ; truc) (; a la place d'une virgule sur le separateur dans le for)

Nope, la "," c'est parce qu'il fait 2 affectations dans l'initialisation de son For, c'est bon ça

Non
Il ya bien trois ; la virgule sert à mettre plusieurs états de départs
 

Tin chui complètement bloqué par cette erreur from outta space

edit : le pire étant que même en mettant un gros n'importe quoi 10 lignes avant, il ne voit toujours que cell-là

Et si tu sors le $this->els = array() du for ?

 
bah ca veut dire que ton erreur est encore plus haut alors

Pareil. De toute façon l'erreur est détectée sur la ligne d'avant, donc a priori c'est soit là soit encore avant.

function fromPost($post, $files) {
                $this->num_set = $post['num_set'];
 
                for ($this->els = array(), $i = 0; $i < count($post['texte']); $i++) {

je parie que l'erreur est au-dessus de tout ça...

Oui ... et?
Pour mémoire, nraynaud essaye de nous expliquer pourquoi les navigateurs devrait empêcher l'envoie des données à un domaine autre que celui de la page courante quand on valide un formulaire de type post (voire ceux en get) . Les considérations du genre "oui, mais en post le proxy, il a pas le droit de mettre en cache la réponse du serveur" sont pour moi en dehors du contexte de cette discussion là.  
 
En résumé : techniquement exact, mais hors sujet.