[AJAX] Kijken hoe request verzonden is

[Verwijderd]

Ik heb een javascript file die d.m.v. AJAX gegevens naar een php file opstuurt en ophaalt.
Dat gebeurt op deze manier:

code:

    http.open('get', '/process.php?action=actieuitvoeren&variabele'+var);
    http.onreadystatechange = handleResponse;
    http.send(null);

Hoe kan ik er nu echter voor zorgen dat wanneer iemand process.php?action=actieuitvoeren&variabele'+var via z'n browser aanroept deze niet thuisgeeft of iig het script niet uitvoert?

[momania]

een post ipv een get doen?
(dat kan toch ook gewoon via de xmlRequest)?

[ Voor 13% gewijzigd door momania op 17-07-2006 22:37 ]

[Verwijderd]

Het hele systeem is al rondom GET gebouwd.

[iH8]

momania schreef op maandag 17 juli 2006 @ 22:36:
een post ipv een get doen?
(dat kan toch ook gewoon via de xmlRequest)?

een POST kan net zo eenvoudig gefaked worden als een GET. met sessies werkt toch een stuk veiliger.

[crisp]

acties die datawijzigingen tot gevolg hebben aan de serverkant dien je sowieso niet met een GET-request te initiëren maar zoals momania al zegt met een POST-request, en ja - dat kan ook met xmlHTTP

[Voutloos]

Een POST kan ook nagedaan worden , alhoewel het misschien wel iets meer werk is. Bovendien ben ik voor het gebruiken van GET en POST zoals ze bedoeld zijn.

Maar goed, afhankelijk van welke actie uitgevoerd wordt kan POST alsnog de natuurlijke actie zijn.

Verwijderd schreef op maandag 17 juli 2006 @ 22:39:
Het hele systeem is al rondom GET gebouwd.

Als je uit principe alleen maar met GET wil werken omdat je het tot nu toe altijd zo doet, werk je imo niet correct. HTTP omvat niet voor niets meer dan alleen GET.

[Verwijderd]

Kan je de variabele in PHP dan weer gewoon ophalen met $_REQUEST[]?

[momania]

Verwijderd schreef op maandag 17 juli 2006 @ 22:39:
Het hele systeem is al rondom GET gebouwd.

Ok, dan bouw je het om?
Zo gek veel werk is dat nou ook weer niet lijkt mij?

Je kan niet aan een 'get' request zien of hij door je javascript of direct in de browser aangeroepen wordt.
Als het verder alleen maar info ophaalt en geen data wijzigd, is die request verder toch onschuldig, en maakt het niet uit als iemand die direct aanroept?

Of wijzigd hij wel data?

[iH8]

Verwijderd schreef op maandag 17 juli 2006 @ 22:47:
Kan je de variabele in PHP dan weer gewoon ophalen met $_REQUEST[]?

kan wel maar als je een POST gebruikt om je data te verzenden is het ook technisch gezien het waterdichtst als je hem gewoon weer met POST ontvangt. request ontvangt GET & POST

[cyberstalker]

Verwijderd schreef op maandag 17 juli 2006 @ 22:47:
Kan je de variabele in PHP dan weer gewoon ophalen met $_REQUEST[]?

Ja, maar dan kun je het dus weer eenvoudig faken met een get. Als je $_POST gebruikt werkt het alleen met postdata .

[SH4D3H]

Met setRequestHeader, kom je misschien in de buurt van een oplossing?
http.setRequestHeader("X_USERAGENT", "SuperGeheimBezigVandaag");

Niet dat het niet te faken is, maar die zooi etterproof krijgen lijkt me toch lastig.

[Verwijderd]

En wat moet ik dan doen in PHP?

[iH8]

Verwijderd schreef op maandag 17 juli 2006 @ 22:55:
En wat moet ik dan doen in PHP?

op je form page start je een sessie en op de page waarop je ontvangt kijk je of er wel een sessie aanwezig is? een speciale useragentstring meesturen en daarop controleren is ook mooi maar ook dat kunnen mensen teruglezen in je javascript. gewoon alleen sessie starten voor diegene die mogen posten.

[r0bert]

Serverside een variabele creeeren aan de hand van een aantal factoren waaronder tijd. Deze serverside registreren met bijv een timeout van 15 min. Dan vanuit de serverside-scripting die variabele meegeven in je pagina met de functie. Dan bij je aanroep van de actie die je wilt invoken, die variabele meegeven en voor het uitvoeren van de actie je variabele (key) vergelijken.

Edit: Zelfde idee als hierboven een beetje

[ Voor 6% gewijzigd door r0bert op 17-07-2006 23:13 ]

[iH8]

r0bert schreef op maandag 17 juli 2006 @ 23:13:

Edit: Zelfde idee als hierboven een beetje

jup maar de jouwe is beter want je werkt met een sessionvar die bij elke post voor elke user weer anders is. challenge/response via sessie. mooi spul.

[funkwurm]

Op het moment dat een het aanroepen van een bestand grote gevolgen heeft server-side (om het algemeen te omschrijven) is het vrij gebruikelijk dat het bestand server-side uberhaupt niks doet tenzij er een sessie bestaat die pas gecreeerd wordt nadat je een inlog-procedure doorstaan hebt en dan nog vertrouw je de user-input niet controleer je die server-side.

Hoe je een inlog-systeem schrijft of serverside input valideert kunnen ze je vast bij programming veel beter uitleggen.

[Voutloos]

funkwurm schreef op dinsdag 18 juli 2006 @ 22:28:
Op het moment dat een het aanroepen van een bestand grote gevolgen heeft server-side (om het algemeen te omschrijven) ...

In die omschrijving kan ik me niet echt vinden. Je kan best simpel uitdrukken wanneer een inlogsysteem nodig is: als er een requirement is voor wat betreft identificatie, integriteit, authorisatie of authenticatie.

Voor de door jou omschreven situatie zou er een requirement zijn in de trant van 'anonieme gebruikers mogen niet dat bestand aanroepen'.