[PHP] Waarde uit link meesturen via POST

[Verwijderd]

Ik zit met deze vraag: is het mogelijk is om via een html link POST variable te versturen naar een php pagina?

Het gaat niet om 1 link, maar om meerdere links, waarbij alleen de waarde van de aangeklikte link moet worden meegestuurd. De waarde verwerken in een hidden field en van de link een submit knop maken, is dus geen oplossing. Voor iedere link een apart formulier maken lijkt me ook te omslachtig.

Ik weet ook dat het wel via de methode GET kan, bijv:

code:

<a href="pagina.php?variabelenaam=linkwaarde1">linkwaarde1</a>
<a href="pagina.php?variabelenaam=linkwaarde2">linkwaarde2</a>

maar ik wil het via de methode POST.

[gorgi_19]

Nope, hooguit een eigen tussenpagina maken, die GET naar POST om ze (en dus ook jouw methodiek gebruikt)

[Verwijderd]

Waarom zou het per se met POST moeten? Ze zijn beide makkelijk te frauderen dus controle op invoer moet je sowieso doen...

[Dutchmega]

Je kan POST variablen meesturen via fsockopen().
Ik weet zelf niet waarom je persee het via POST wil terwijl het prima via GET kan?

[TheDane]

Je kunt een form maken waarin alle url -get variables als variables zijn gedupliceerd.

en dan aan dat tekstlinkje een onclick submit form event hangen?

ik snap trouwens ook niet waarom je perse wil posten?

[Verwijderd]

Misschien klopt het niet, maar ik heb gelezen dat de POST methode veiliger is dan de GET methode.
En onderhand ben ik zelfs als het wat veiligheid betreft niet uitmaakt, door al mijn zoeken-en-niet-vinden benieuwd of het mogelijk is.
Als beginnend PHP-er kan ik in de -schetsmatige- reacties nog geen werkende oplossing lezen.

Beste TheDane, zou je je suggestie iets meer kunnen toelichten zodat ik kan begrijpen wat je bedoelt met deze zin:
'Je kunt een form maken waarin alle url -get variables als variables zijn gedupliceerd. '

[ Voor 42% gewijzigd door Verwijderd op 29-11-2004 12:18 ]

[Verwijderd]

User input is nooit te vertrouwen, of het nu gaat om waardes via GET of POST. Zorg ervoor dat je goed controleert of de data die je van de user krijgt geldig is en het resultaat oplevert die verwacht wordt. Zorg dus dat als je een positieve integer verwacht dat de waarde ook daadwerkelijk een positieve integer is etc... Of je nu POST of GET gebruikt zou niet moeten uitmaken wat security betreft, maak het jezelf gewoon niet te moeilijk

[MJV]

En wat is de meerwaarde van omzetten naar POST als die POST variabele simpelweg bestaat uit de waarde uit de GET variabele? 0,0 Lijkt me.

Dus zorg gewoon dat je de variabelen die via $_GET en $_POST binnenkomen altijd controleerd.

Ook bijv. als je aan een veld maxlength="4" betekent dat niet veel, iemand die kwaad wil kan zoiets binnen no-time omzeilen.

[ Voor 23% gewijzigd door MJV op 29-11-2004 13:39 ]

[NMe]

DutchBlood schreef op maandag 29 november 2004 @ 13:37:
Dus zorg gewoon dat je de variabelen die via $_GET en $_POST binnenkomen altijd controleerd.

En $_SESSION, en $_COOKIE, en $_REQUEST.

[Verwijderd]

Beste reageerders,

De reacties tot nu toe geven niet zozeer een antwoord op mijn vraag of inzicht in de mogelijkheden maar zeggen zoiets als: 'dat moet je niet willen'.

Ik ben aan het zoeken & nieuwsgierig. Ik zou het fijn vinden als iemand een antwoord kan geven op mijn vragen:
1. is het mogelijkom dit via POST te doen?
2. Zo ja hoe / zo nee, waarom niet?

[mulder]

1) Nee dus
2) Een click op een link doet geen POST

[NMe]

Verwijderd schreef op maandag 29 november 2004 @ 13:50:
Beste reageerders,

De reacties tot nu toe geven niet zozeer een antwoord op mijn vraag of inzicht in de mogelijkheden maar zeggen zoiets als: 'dat moet je niet willen'.

Ik ben aan het zoeken & nieuwsgierig. Ik zou het fijn vinden als iemand een antwoord kan geven op mijn vragen:
1. is het mogelijkom dit via POST te doen?
2. Zo ja hoe / zo nee, waarom niet?

HTML:

<form action="volgendepagina.php" method="post" name="formpje">
<input type="hidden" name="variabelenaam" value="" />
</form>

<a href="volgendepagina.php?variabelenaam=2" onclick="document.formpje.variabelenaam.value = '2';
      document.formpje.submit(); return false;">Linkje</a>

Zoiets zou moeten werken. Maar het heeft werkelijk geen enkel nut.

[ Voor 47% gewijzigd door NMe op 29-11-2004 14:52 ]

[Verwijderd]

Het kan wel met een work arround, maar je schiet er niks mee op!!! Wat TheDane volgens mij bedoelde heb ik even voor je uitgewerkt...

HTML:

<script type="text/javascript">

function Navigate(page, var)
{
    // plaats waarde in het forrmulier
    document.getElementById("var").value = var;
    // geef pagina op waarheen het formulier moet submitten
    var frm = document.forms('navaigation');
    frm.action = page;
    frm.submit();
}

</script>


<form name="navigation" id="navigation" action="" method="post">
    <input type="hidden" id="var" name="var" value="">
</form>

<a href="#" onclick="Navigate('page.php','1')">

[edit 1]

ik moet wat aan mn snelheid gaan doen....

[edit 2]

Volgens mij gaatie van -NMe- niet goed werken omdat hij tevens een href in z'n anchor heeft staan.

[ Voor 45% gewijzigd door Verwijderd op 29-11-2004 14:00 ]

[TheDane]

Verwijderd schreef op maandag 29 november 2004 @ 13:57:
Het kan wel met een work arround, maar je schiet er niks mee op!!! Wat TheDane volgens mij bedoelde heb ik even voor je uitgewerkt...

HTML:

<script type="text/javascript">

function Navigate(page, var)
{
    // plaats waarde in het forrmulier
    document.getElementById("var").value = var;
    // geef pagina op waarheen het formulier moet submitten
    var frm = document.forms('navaigation');
    frm.action = page;
    frm.submit();
}

</script>


<form name="navigation" id="navigation" action="" method="post">
    <input type="hidden" id="var" name="var" value="">
</form>

<a href="#" onclick="Navigate('page.php','1')">

[edit 1]

ik moet wat aan mn snelheid gaan doen....

[edit 2]

Volgens mij gaatie van -NMe- niet goed werken omdat hij tevens een href in z'n anchor heeft staan.

dit is inderdaad wel precies wat ik bedoelde ja

en wat hierboven ook ergens staat: 't heeft werkelijk geen enkel nut, tenzij je absoluut geen getvariabelen in je url wilt terugzien, maardannog zie ik het nut niet

[Verwijderd]

Mocht je ooit aan zoekmachineoptimalisatie gaan doen is deze methode sowieso uit den bozen! De zoekmachine kan namelijk geen andere pagina vinden dan de pagina die je te zien krijgt als je je domeinnaam intypt. Maar goed deze info is niet relevant als de zoekmachine jouw interesse niet heeft...

[NMe]

Verwijderd schreef op maandag 29 november 2004 @ 13:57:
Volgens mij gaatie van -NMe- niet goed werken omdat hij tevens een href in z'n anchor heeft staan.

Jawel, dit is zelfs beter. Wanneer Javascript uit staat, zal je toch nog op de site kunnen browsen d.m.v. GET-variabelen. Maar dat moet je dan inderdaad wel afvangen in je volgende pagina, dus heb je er waarschijnlijk nog niets aan.

@TS: Punt is, dat je site nu niet zal werken bij iemand die Javascript uit heeft staan, en bovendien levert het een beveiligingsincrease van nul komma nul op. Verder krijg je dan elke keer als je je pagina refresht de vraag "of je de POST-waardes opnieuw wil versturen", best irritant. Steek liever je tijd in echte beveiliging dan in onzin als dit.

Edit:

Verwijderd schreef op maandag 29 november 2004 @ 14:49:
Mocht je ooit aan zoekmachineoptimalisatie gaan doen is deze methode sowieso uit den bozen! De zoekmachine kan namelijk geen andere pagina vinden dan de pagina die je te zien krijgt als je je domeinnaam intypt. Maar goed deze info is niet relevant als de zoekmachine jouw interesse niet heeft...

En dat is nog een reden waarom die code van mij beter functioneert. Google zal die href gewoon volgen, terwijl een normale gebruiker via post browst.

[ Voor 35% gewijzigd door NMe op 29-11-2004 14:51 ]

[Verwijderd]

hmm ik dacht dat in jouw idee de href en submit van een form een conflict zou opleveren... maar goed, winst is 0.0, daar zijn we wel over uit

[NMe]

Verwijderd schreef op maandag 29 november 2004 @ 14:53:
hmm ik dacht dat in jouw idee de href en submit van een form een conflict zou opleveren... maar goed, winst is 0.0, daar zijn we wel over uit

Die "return false" achteraan zorgt ervoor dat de standaard functionaliteit die na een onclick wordt uitgevoerd wordt tegengehouden, meen ik te weten met mijn redelijk beperkte JS kennis.

[Verwijderd]

Beste NMe en Sooterd,

Bedankt voor jullie input. Ik ga hier eens mee aan de gang. En natuurlijk nog eens links en rechts lezen over veiligheid bij de twee verschillende methoden GET en POST. Ik begreep dat je bij GET het toevoegen van waarden om te beginnen al makkelijker maakt omdat je via de url+vraagteken al een waarde op kunt geven voor een variabele.
Maar goed, ik ben een beginner wat dat betreft.
Nogmaals bedankt tot zover.

[Verwijderd]

De veiligheid ligt niet aan de methodes, maar aan de implementatie daarvan in je systeem. Neem dat maar aan, dan ben je niet met nutteloze zaken als dit bezig...

Maar voor de rest graag gedaan

[NMe]

Verwijderd schreef op maandag 29 november 2004 @ 15:02:
Beste NMe en Sooterd,

Bedankt voor jullie input. Ik ga hier eens mee aan de gang. En natuurlijk nog eens links en rechts lezen over veiligheid bij de twee verschillende methoden GET en POST. Ik begreep dat je bij GET het toevoegen van waarden om te beginnen al makkelijker maakt omdat je via de url+vraagteken al een waarde op kunt geven voor een variabele.
Maar goed, ik ben een beginner wat dat betreft.
Nogmaals bedankt tot zover.

Als ik nu op mijn eigen server een formulier maakt, dat een POST maakt naar jouw PHP-pagina, dan kan ik zo ook variabelen invullen. Dus wat schiet je er dan mee op? Je maakt alleen je site ontoegankelijker voor de gewone gebruiker, een "hacker" komt ook wel om die kleine "beveiliging" heen...

[MJV]

Verwijderd schreef op maandag 29 november 2004 @ 15:02:
Beste NMe en Sooterd,

Bedankt voor jullie input. Ik ga hier eens mee aan de gang. En natuurlijk nog eens links en rechts lezen over veiligheid bij de twee verschillende methoden GET en POST. Ik begreep dat je bij GET het toevoegen van waarden om te beginnen al makkelijker maakt omdat je via de url+vraagteken al een waarde op kunt geven voor een variabele.
Maar goed, ik ben een beginner wat dat betreft.
Nogmaals bedankt tot zover.

http://phpfreakz.nl/artikelen.php?aid=106

Een artikel over veel elementen van beveiliging, met php als uitgangspunt, maar van toepassing op elke programmeertaal.

[Tha Ertenal]

lol, je kan ook gewoon een form maken. En ipv een ok-button een stukje tekst neerzetten. Gaat wat makkelijker he

[Verwijderd]

Zie hier een uitleg over wat het verschil is tussen GET en POST, en in welk geval je welke methode moet gebruiken (Ze zijn niet uitwisselbaar!). Ik heb het stuk zelf niet gelezen (alleen er op geGoogled en het eerste stuk dat naar boven kwam doorgekeken; het ziet er goed uit). Je kan er ook de HTTP specificatie op na slaan natuurlijk.

Een voorbeeld (echt probleem van een vriend van me), hij had een Wiki waarin een een link gebruikt wordt (GET request), om een pagina te reverten naar een vorige versie. Aangezien de specificatie zegt dat GET links in principe zo vaak opgevraagd mogen worden als je wilt zonder dat er iets verandert, kan het gebeuren dat web spiders (Google of MSN, dus) die GET link opvragen en op die manier de Wiki reverten.

Pagina's met GET parameters zijn verder copy/pastebaar; pagina's met POST parameters zijn dat niet.

Naar pagina's met GET parameters is terug te gaan met je browser's back button, naar POST pagina's niet zonder een irritant repost dialoog te krijgen (wat correct gedrag is van de browser, maar duidt op slecht site-ontwerp).

[Verwijderd]

Verwijderd schreef op dinsdag 30 november 2004 @ 13:16:
Naar pagina's met GET parameters is terug te gaan met je browser's back button, naar POST pagina's niet zonder een irritant repost dialoog te krijgen (wat correct gedrag is van de browser, maar duidt op slecht site-ontwerp).

Daar ben ik het dus helemaal niet mee eens. Je kan er ook voor kiezen om met POST te gaan werken zodat de gebruiker niet eventjes een variabele in de URL kan veranderen.Bovendien zit je met GET aan een limit van bytes en bij POST niet. Ook vind ik persoonlijk het niet netjes om alles maar te tonen in de URL, tevens hoeft bij POST geen encoding te gebruiken.

Don Facundo schreef op maandag 29 november 2004 @ 13:52:
1) Nee dus
2) Een click op een link doet geen POST

Use een Javascript methode...


function voerUit(var){
document.getElementById('orderId').value = var;
document.getElementById('myFormOrder').submit();
}

link

Modbreak:

de groeten doen en je eigen site spammen doe je maar in je sig

[ Voor 22% gewijzigd door Creepy op 14-12-2004 20:32 . Reden: Site verwijderd ]

[Verwijderd]

Als je dit überhaupt toepassen wilt, zou ik er wel voor zorgen dat iemand zonder javascript het ook nog gebruiken kan. Ook moeten zoekmachines, die ook geen javascript lusten, het nog begrijpen. Daarom zou ik gaan voor deze client-side java-oplossing

JavaScript:

window.onload = function()
{
    var anchors = document.body.getElementsByTagName('a');

    for(var i=0;i<anchors.length;i++)
    {   //Ga alle anchors af, en gooi er een onclick handler bij
        anchors[i].onclick = new Function('postRequest(this);return false;');
    }
}

function postRequest(anchor)
{
    var form = document.createElement('form');
    form.method='POST';

    //Ga alle GET-elementen af
    var vars = anchor.href.substring(anchor.href.indexOf('?')+1).split('&');
    
    for(var i=0,pos,value;i<vars.length;i++)
    {
        pos=vars[i].indexOf('=');
        value= document.createElement('input');
        value.name=vars[i].substring(0,pos);
        value.value=vars[i].substring(pos+1);
        form.appendChild(value);
    }

    document.body.appendChild(form);
    form.submit();
}

Met dit bovenstaand script is het voor iedereen nog mogenlijk om je site te gebruiken. Ik betwijfel of dit eigenlijk ook maar een beetje nut heeft. Het enige wat je er bij wint is het weghalen van waarden uit de refer.

[ Voor 5% gewijzigd door Verwijderd op 14-12-2004 16:36 . Reden: Function ipv function, kleine typo ;) ]

[Erkens]

Tha Ertenal schreef op dinsdag 30 november 2004 @ 12:48:
lol, je kan ook gewoon een form maken. En ipv een ok-button een stukje tekst neerzetten. Gaat wat makkelijker he

of je button zo stylen dat het een normale textlink lijkt

[Verwijderd]

Verwijderd schreef op dinsdag 14 december 2004 @ 15:16:
[...]
Daar ben ik het dus helemaal niet mee eens. Je kan er ook voor kiezen om met POST te gaan werken zodat de gebruiker niet eventjes een variabele in de URL kan veranderen.

Een echte kwaadwillende gebruiker kan het tòch wel veranderen. Security by obscurity is, voor de zoveelste maal, geen security.

Verder hoort het geen probleem te zijn dat de gebruiker een parameter kan veranderen; als hij gewoon een andere parameter op wil geven zonder opnieuw door een scherm heen te gaan moet dat toch kunnen? En je hoort de validatie van invoergegevens tòch te doen in je script. Je kunt niet denken `oh, de variabele komt uit een POST, daar kan niet mee gerommeld worden (FOUT!), dus die kan ik wel vertrouwen'.

Het voegt niets toe en neem wel gebruiksgemak weg: URL hacking is een feature, geen bug.

Bovendien zit je met GET aan een limit van bytes en bij POST niet.

Dat is waar, maar als je over de limiet heen gaat is dat waarschijnlijk omdat je gegevens aan het versturen bent. Gegevens versturen moet sowieso in een POST, vanwege de aard van de actie.

Ook vind ik persoonlijk het niet netjes om alles maar te tonen in de URL

Waarom niet?

Een ervaren gebruiker kan wat met die informatie, zoals URL-hacken, of het URl copy/pasten naar andere programma's of gebruikers, en zal zeker niet geïntimideerd worden door een lang URL. En een onervargen gebruiker zal het niet merken omdat hij toch niet op de adresbalk zal letten als hij door de site heen klikt. Het enige waar je dan op moet letten is dat entry URLs voor je site beheersbaar en leesbaar zijn.

Let wel, je bent behoorlijk vaag met je `alles'. Ik ben ook niet aan het aanraden om alle http requests via GET te laten verlopen. Wat ik probeer te doen is aangeven dat er een wezenlijk verschil is tussen GET en POST en dat je als je een goede site wilt ontwerpen, je wel degelijk moet weten in welk geval je GET en in welk geval je POST dient te gebruiken. Het is dus geen kwestie van smaak of vrije keus!

, tevens hoeft bij POST geen encoding te gebruiken.

Tja, daarbij doet de browser de encoding (vergis je niet, het gebeurt nog steeds!). Maar dit is gewoon een puur lamheids-argument. Wil je goede websites maken, of vind je houtje-touwtje sites ook al goed?

[ Voor 3% gewijzigd door Verwijderd op 14-12-2004 16:47 ]

[drm]

Heb je er al eens over nagedacht dat hier mensen zitten die weten waar ze het over hebben? En dat mensen die sites proberen te hacken meestal ook wel weten waar ze het over hebben? Dat ze dus hetzelfde denken over linkjes vervangen door POST requests, en dat dan juist die hackers bij een site die alle linkjes vervangt door POST requests zullen denken: Goh, best kans dat die prutser goede man een behoorlijk lekke site heeft?

Something to think about.

[NMe]

Verwijderd schreef op dinsdag 30 november 2004 @ 13:16:
Naar pagina's met GET parameters is terug te gaan met je browser's back button, naar POST pagina's niet zonder een irritant repost dialoog te krijgen (wat correct gedrag is van de browser, maar duidt op slecht site-ontwerp).

Verwijderd schreef op dinsdag 14 december 2004 @ 15:16:
Daar ben ik het dus helemaal niet mee eens.

Ik zie de samenhang tussen jouw post en het stuk dat je aanhaalt niet echt. Je zegt dat POST voordelen heeft (wat slechts in bepaalde gevallen echt opgaat, zie OneOfBorg's reply), maar je zegt niets over dat nadeel, wat wel degelijk een nadeel is. Het is heel vervelend om telkens een popup te krijgen wanneer je op back duwt in je browser; ik zou om die reden een andere site zoeken om mijn info vandaan te halen.

[Verwijderd]

Het is voor kwaadwillende net zo makkelijk om POST variablen aan te passen als dat het is om GET variabelen aan te passen. Ze moeten een paar stappen meer nemen, maar dat houd echt nagenoeg niemand tegen. Het enige voordeel wat er aan vast kan zitten is dat misschien user-afhankelijke waarden niet in de 'Referer' header komen, zodat volgende sites deze gegevens niet kunnen misbruiken. En de kans dat zoiets überhaupt gebeuren zal is eigenlijk niet bijster groot. Dus, Rob, gebruik gewoon anchor-tags waar ze voor bedoelt zijn, en laat het browsen gewoon gaan zoals het 'hoort' te gaan. Je hebt nu een paar voorbeelden gezien waarop het mogenlijk is om het anders te doen, maar dat betekent nog niet dat je het daadwerkelijk anders moet gaan doen .

[Verwijderd]

Het is voor kwaadwillende net zo makkelijk om POST variablen aan te passen als dat het is om GET variabelen aan te passen. Ze moeten een paar stappen meer nemen, maar dat houd echt nagenoeg niemand tegen.

Jullie hebben ook gelijk, en ik blijf ook eigenwijs Ik vind het makkelijker om in een URL even een
http://pagina.nl/afbeelding1.jpg in afbeelding2.jpg veranderen. En ook weet ik wel dat het ook met een post gedaan worden. Maar dan moet ik iig een klein beetje html kunnen en de moeite er voor nemen.

greetz

[NMe]

Verwijderd schreef op dinsdag 01 februari 2005 @ 00:40:
Jullie hebben ook gelijk, en ik blijf ook eigenwijs Ik vind het makkelijker om in een URL even een
http://pagina.nl/afbeelding1.jpg in afbeelding2.jpg veranderen. En ook weet ik wel dat het ook met een post gedaan worden. Maar dan moet ik iig een klein beetje html kunnen en de moeite er voor nemen.

greetz

Ken je de webdeveloper toolkit voor Firefox? Een klik, en je zet post variabelen om naar get variabelen of andersom. Ik zie het verschil in moeite dus niet.

[T-MOB]

-NMe- schreef op dinsdag 01 februari 2005 @ 00:45:
[...]

Ken je de webdeveloper toolkit voor Firefox? Een klik, en je zet post variabelen om naar get variabelen of andersom. Ik zie het verschil in moeite dus niet.

Je hebt helemaal gelijk hoor, maar West heeft het over het aanpassen van URL. Dat is volgens mij iets van F6 en dan aanpassen maar. Mijn gebruikers mogen dat best, als niemand het spul zou mogen zien zou ik het niet on-line plaatsen. Magoed * T-MOB vindt het eigenlijk gewoon nutteloze kick... waar ie dan toch weer aan meewerkt

[NMe]

T-MOB schreef op dinsdag 01 februari 2005 @ 02:37:
Je hebt helemaal gelijk hoor, maar West heeft het over het aanpassen van URL. Dat is volgens mij iets van F6 en dan aanpassen maar. Mijn gebruikers mogen dat best, als niemand het spul zou mogen zien zou ik het niet on-line plaatsen. Magoed * T-MOB vindt het eigenlijk gewoon nutteloze kick... waar ie dan toch weer aan meewerkt

Hij zegt dat het aanpassen van de URL makkelijkers is dan het het aanpassen van waarden die via POST binnenkomen, en ik ontkrachtte dat.

[pjonk]

Ik gebruik POST requests alleen of als ik heel veel data moet versturen dat niet in een GET request past of als de actie van de client een wijziging in de database tot gevolg heeft.

Voorbeeld
In mijn CMS had ik een script waarmee ik een image kon bekijken en verwijderen met respectievelijk de volgende URI's:
image.php?action=view&id=1
image.php?action=remove&id=1

Het bekijken van een image heeft geen wijzigingen in de DB tot gevolg dus hier gebruik ik een GET request. Het verwijderen van een image heeft echter een actie in de DB tot gevolg en daarom heb ik voor een POST request gekozen. Gewoon een stukje extra veiligheid omdat je een POST niet zomaar in je browser kunt verversen zonder eerst een waarschuwing voor je snufferd te krijgen.

[Verwijderd]

Anders een sessie.

Als je op de eerste pagina komt etc.

code:

$_SESSION['mYlink'] == $_SERVER['benevenkwijthoedieheet'];

Maar iig de ding dat je opgeeft wat eerste url was?

kun je bij de post zeggen van

code:

if(isset($_SESSION['mYlink']) && $_SESSION['mYlink'] == 'url') {

Weet niet of je dit bedoeld.

[ Voor 15% gewijzigd door Verwijderd op 01-02-2005 09:19 ]