On Sun, Jun 17, 2012 at 12:45:43PM +0100, Srdjan Todorovic wrote:
On 17 June 2012 12:23, Chris Green cl@isbd.net wrote:
requests it and the client fills in the form. ??The trouble is that there's no direct way for the PHP script that created the form to get the result - at least there isn't in any of the environment/frameworks that I've used.
Back in the day when everyone generally thought PHP was a good language to do web development in, I played about a little with PHP.
A very dirty, hacky, nasty way to do this is to call the same php script, with your <form> having a hidden input field. The PHP script checks it and does different things depending on the value. As I said, very nasty.
The idea isn't wrong, as long as the hidden input field is used as a session key. But by today's standards, any sane web application environment should come with a reasonable session facility, so application programmers shouldn't re-invent that.
Generating the session key isn't too difficult, but getting the server side logic right (timeouts, reasonable defences against session hijacking etc.) is a quite considerable amount of work that should be left to container designers / developers.
What happens is that there is *another* script which gets run (server side) when the client submits the form duly filled in. ??This other script has no direct connection with the script that created the form, no common environment, nothing.
Would something like a session key help? (I have no idea) Script 1 generates a session key, creates a bunch of settings from the form, saves to DB or somewhere, calls script 2 with same session key. Script 2 grabs data relating to session key and carries on.
I can't help but think that's not secure: malicious agent could try to determine or brute force session keys until a valid one is selected, at which point whatever action that session key relates to, would get executed (again). Maybe there's some potential for information leakage? Who knows. Not touched PHP for 10 years.
When processing a session key, the server can check whether the request comes from the host that it has sent the key to in the first place. Using HTTPS provides further protection.
I bet I will get laughed at by everyone else, since my suggestion must be so silly.
Not really -- the idea of using sessions to overcome limitations of HTTP statelessness is entirely reasonable. Implementation practices of contemporary web containers are a bit more refined in some aspects, though, e.g. session data normally is kept in some server process rather than stored in a database.
Best regards, Jan