| 2:02 pm on Jun 26, 2008 (gmt 0)|
You could do it by echoing the values you want to store into hidden form fields, and making all your navigation do postbacks via POST or GET, ASP.NET style. However, be aware that any saavy user can read these values, and it really decreases the security of the site.
Use a screwdriver on the screw, not a hammer. :) $_SESSION is your best bet for this.
| 2:45 pm on Jun 26, 2008 (gmt 0)|
I was afraid of that...
I have a few pages that use a php PDF class, and for whatever reason I can't declare session or use start_session on the same page that this PDF class is used.
Which really stinks because in order to get the users member information I have to echo all the users information into a form with hidden fields, submit the form and reload the page, and then I can read the post data into the PDF.
Functional? Yes. Messy? very.
| 3:24 pm on Jun 26, 2008 (gmt 0)|
Interesting that a PDF class would break it. Have you looked into any alternatives?
Alternately, perhaps a custom session handler would work. Do you have a database available? If so, I can provide a simple database session handler I wrote. It's simple, but it does the trick. On the off-chance that you're using CodeIgniter, I have a library that plugs into that easily as well. :)
| 4:53 pm on Jun 26, 2008 (gmt 0)|
The only reason that I could think of that session might mess it up is if it somehow alters the header information?
If you want to play around with it, its from [ros.co.nz...]
$pdf =& new Cezpdf();
$pdf =& new Cezpdf();
fails without an error, just page cannot be displayed.
I do have a database available, but would it be able to keep informations straight for multiple users over multiple pages if there is no session info or id available from page to page?
| 6:28 pm on Jun 26, 2008 (gmt 0)|
It also adds a bit of validation--though you can disable it, by default it will check and make sure the user agent and IP address match what was received in the last request.
Unfortunately, it's about 100 lines of code, and the SQL script to create the table is another 10--plus, this forum destroys formatting. Sticky me your e-mail address and I'll e-mail the files to you. :)
| 8:25 pm on Jun 26, 2008 (gmt 0)|
Hmm, I am intrigued...
I have a html form that has been getting some spam, but they aren't using the actual webpage to send the spam, just spoofing the headers and sneaking it through.
I don't know if it would work, but it might be interesting to use this session stuff to make sure that the people that are submitting the form are at least going to the webpage, instead of just automating stuff.
| 6:01 am on Jun 27, 2008 (gmt 0)|
>> fails without an error, just page cannot be displayed.
This sounds like a fatal PHP error to me. Have you actually tried looking in your error logs to see if something is coming up in there?
>> I have a html form that has been getting some spam
This is a common issue and yes, it can be solved with sessions. Have a look at something called CAPTCHA and you will see some common implementations of it. There are other methods, too, and a few of them are explained in a thread we keep in the forum library: Combatting webform hijack [webmasterworld.com].
| 1:42 pm on Jun 27, 2008 (gmt 0)|
We've talked about CAPTCHAs, but its an order form, and I don't think people should have to jump through hoops to buy stuff from us.
I think that if I make it so that the person is submitting the form has to do it from the actual original web page, it might be to much trouble for them and it'll taper off.