[PHP]Variabele via href zetten

[bibawa]

Hoi,

Ik maak in mijn website gebruik van het systeem waarmee pagina's worden veranderd adhv de waarde die in de url staat. bv

http://www.mijnsite.be/index.php?p=zoek

waarna dus zoek.php getoond zal worden.
Op zich werkt dit systeem goed en vind ik dit ook wel OK, maar nu ben ik begonnen met de ontwikelling van een PMbox systeem en het is niet de bedoeling dat de gebruikers via de url het getoonde bericht kunnen opvragen (dus dat ze niet rechtstreeks naar http://www.mijnsite.be/index.php?p=pm&bericht=123456 kunnen surfen.

Om dit te omzeilen zouden er variabelen "achter de schermen" ingesteld moeten worden als de gebruiker bv op de link van een bericht klikt. Een variabele zou dus zijn het berichtId.

Ik zou dit kunnen oplosen door te werken met een sessie, maar dan los ik het probleem nog niet op dan moet ik nog steeds het een en ander in de url meegeven om de sessie in te stellen.

NU: bestaat er in php zo niets zoals in javascript het OnClick event? als dit nu zou bestaan dan zou ik bij het klikken op een knop gewoon een functie kunnen aanroepen die een variabele insteld. en dit zou prachtig zijn

Dus kan dit op deze manier ?

[Robtimus]

POST gebruiken ipv GET. Dan worden de parameters wel doorgegeven maar niet zichtbaar in de browser.

[Creepy]

Nee dat bestaat niet, nogal logisch lijkt me.

Waarom wil je dat eigenlijk afschermen? Als iemand zo een eigen bericht wilt lezen lijkt me dat geen probleem.

Het verschil tussen post en get is bijna niks, ok, je ziet geen url var's op de browser maar een post request is net zo makkelijk samen te stellen als een get als je ene beetje handig bent en met een post staan de id's e..d ook nog steeds in de broncode van je pagina. Dus nog steeds niks "achter de schermen"

[ Voor 50% gewijzigd door Creepy op 19-11-2007 22:10 ]

[Pyrus]

Je kunt natuurlijk ook gewoon post ipv get gebruiken.
Daarnaast draait PHP serverside en heeft dat dus geen biet te maken met wat je de bezoeker voorschotelt; tenminste niet op de manier dat javascript dat heeft.

Maak je echter geen illusie, ook post is gemakkelijk te neppen. Iets moeilijker dan get, dat wel, maar nog steeds heel gemakkelijk.
Als niet iedereen bij een bepaald stuk content (de pm's van iemand anders) mag komen zul je het af moeten schermen met een username/password combo.

[bibawa]

Ik vind dit systeem niet echt "veilig" als iemand begint te klooien met de nummers (wat gewoon autonummers zijn) dan zou hij berichten kunnen lezen van andere gebruikers (hier tegen moet je je natuurlijk beschermen)

[Creepy]

bibawa schreef op maandag 19 november 2007 @ 22:10:
Ik vind dit systeem niet echt "veilig" als iemand begint te klooien met de nummers (wat gewoon autonummers zijn) dan zou hij berichten kunnen lezen van andere gebruikers (hier tegen moet je je natuurlijk beschermen)

Ik had gehoopt dat je hier niet mee zou komen. Ik nam aan dat je iets in een sessie zou zetten om aan te geven dat iemand succesvol is ingelogt en dat je een bericht aan een gebruiker had gekoppeld. Dan is een check of iemand een bericht mag bekijken een kleine moeite en niet meer dan logisch gezien de site die je aan het maken dan.
Wil je nu zeggen dat je hier zelf nog niet aan hebt gedacht?

[ Voor 9% gewijzigd door Creepy op 19-11-2007 22:13 ]

[Dennahz]

Dit is zogenaamde schijnveiligheid. Er zullen echt wel mensen zijn die gaan proberen en dan ineens in andermans PB boxje zitten. Je zult moeten werken met rechten. Is de ingelogde user de ontvanger van het bericht? Zo ja > laten zien. Zo nee > Error.

[Evilbee]

Wat je ook kan doen is aan de url nog een unieke hash meegeven. Zodat een je gaat zoeken op de ID en de hash. En daar zijn eindeloze combinaties van.

http://www.mijnsite.be/in...456&hash=rgvsdtu7632fnuyy

[Confusion]

Evilbee schreef op dinsdag 20 november 2007 @ 08:33:
Wat je ook kan doen is aan de url nog een unieke hash meegeven. Zodat een je gaat zoeken op de ID en de hash. En daar zijn eindeloze combinaties van.

http://www.mijnsite.be/in...456&hash=rgvsdtu7632fnuyy

Dan kan je net zo goed gewoon sessies gebruiken: die gebruiken immers ook een uniek sessionID, dat met alle requests wordt meegegeven, maar daarmee kan je meteen nog veel meer persoonlijke informatie aan een unieke ingelogde gebruiker koppelen.

[frickY]

Hij bedoeld denk ik eerder dat je ook een hash van het ID opneemt, zodat je het kunt zien wanneer het ID wordt gewijzigd.

mijnsite.be?p=pmbox&bericht=1234&hash=abcdefgh

PHP:

if(empty($_GET['bericht']) || empty($_GET['hash']) || md5($_GET['bericht'] . 'salt') != $_GET['hash']) {
   exit('gaat eens dood');
}

Zo kan men het ID niet wijzigen zonder dat de hash ongeldig wordt. De hash kunnen ze niet wijzigen want ze kennen de geheime salt niet.

[ Voor 18% gewijzigd door frickY op 20-11-2007 08:59 ]

[djiwie]

IceManX schreef op maandag 19 november 2007 @ 22:06:
POST gebruiken ipv GET. Dan worden de parameters wel doorgegeven maar niet zichtbaar in de browser.

POST is bedoeld voor acties die daadwerkelijk iets uitvoeren (zoals het versturen van een formulier), GET voor alle overige acties (zoals het tonen van een bericht). Liever niet dus.

@TS: je probeert nu security by obscurity te implementeren, dat lijkt me geen goed idee. Zorg ervoor dat alleen gebruikers voor wie het bericht bedoeld is het bericht kunnen openen, en geef anders een error. Je gebruikers kunnen dan wel het ID in de URL veranderen, maar ze zullen er niet ver mee komen.

[Muthas]

Inderdaad, anders zaten vele tweakers hier ook al lang in HK door /31 in te typen bij topic listing