User not logged in - login - register
Home Calendar Books School Tool Photo Gallery Message Boards Users Statistics Advertise Site Info
go to bottom | |
 Message Boards » » PHP - Pass _GET variables but make sure no changes Page [1]  
bous
All American
11215 Posts
user info
edit post

I am making a page with multiple links on it that link to another php page. There are some numbers in these links I don't want people to be able to change. What is the best way to do this?

Run down:

User inputs some information and it goes to a new page with tables of data generated from their input. Then the user can click links for each set of data and it passes a number I don't want them to be able to change to a php page. The php page then generates a pdf file using that number. It needs to be created on the fly.


encrypt _GET? session?

needs to be done w/o storing a cookie and without requiring them to login and without having to re-calculate the information on the page they clicked on.

does NOT need to be secure. only want to make sure they can't change something.

6/15/2007 1:40:54 PM

jimmy123
Veteran
395 Posts
user info
edit post

if nobody answers your question here, the boys on irc.freenode.net #php can be quite helpful for quick help.

6/15/2007 2:16:54 PM

robster
All American
3545 Posts
user info
edit post

You could use two parameters and just make it a hash it out so that the page only processes if the parameters are together valid.

When I need something like that, and its in a system where the user cookie has already been set for security purposes, I run a check to make sure that the item being edited or viewed is something that belongs to that user (by referring back to the userid in the table for that item in the database) and then either display or do not display based on that check. Its simple, and can be tweaked to work for most scenarios...

6/15/2007 6:22:29 PM

Raige
All American
4386 Posts
user info
edit post

I see two options here.

1) change the look to use forms (hidden variables etc... but not so pretty and not very adjustable without a lot of work).

2) use session variables. I don't know how to do this in PHP but I'm pretty sure it's simple. Just look it up here --> http://us2.php.net/session

6/15/2007 7:06:57 PM

Stein
All American
19842 Posts
user info
edit post

You answered your own question. Sessions are the more elegant way to do it, though just encrypting/hashing the GET variables (you can even combine them to do this) is just as valid.

6/15/2007 8:54:47 PM

crazyOx
New Recruit
12 Posts
user info
edit post

if you want to send the variables to just another page without them showing up in the URL, then you can use the post method instead of the get method.

There are tradeoff though. Get is faster than post. Post is more secure than get. You could look this up. If you need the same number to be stored on multiple pages, then use sessions as specified by some of the other people who have replied.

6/15/2007 10:21:11 PM

Stein
All American
19842 Posts
user info
edit post

Switching to POST variables doesn't solve his problem as they can be easily modified.

6/16/2007 1:03:56 AM

crazyOx
New Recruit
12 Posts
user info
edit post

I'm confused here. How will it be modified if the processing is being done by the server? The user can't see how the server processes the input.

6/16/2007 1:07:00 AM

Stein
All American
19842 Posts
user info
edit post

The user can modify the POST variables any number of ways inbetween the load of the page and the submission of the form.

It's "more secure" only because it's slightly less convenient to do.

6/16/2007 1:19:30 AM

crazyOx
New Recruit
12 Posts
user info
edit post

ok. If get and post cannot be modified, then what form methods can one use that can't be modified? This is interesting.

[Edited on June 16, 2007 at 1:31 AM. Reason : bad spelling]

6/16/2007 1:31:20 AM

Stein
All American
19842 Posts
user info
edit post

You use either of them or sessions. It's not really a matter of using something else, but more an issue of making sure that the data you get is valid.

6/16/2007 1:39:52 AM

Raige
All American
4386 Posts
user info
edit post

^ the reason i mentioned form variables at all was because you said it didn't need to be secure. If someone really wants to falsify the form data it's possible for them to figure things out and do it. They can't set a session variable as easy. Now, the way PHP handles sessions may differ from Cold Fusion so Stein would be the guy to talk to here about that.

Session variables are much easier to keep track of because you put them in once and they are there. Form variables you have to continue to pass them from each page to the next so your code can get clunky.

6/16/2007 7:13:52 AM

slut
All American
8357 Posts
user info
edit post

I prefer to hash out the two numbers over a session variable, but if i just hash a number and someone knows what number they want, they can just hash it themselves and replace it in _GET. I'll try both and do it that way. I never trust GET or POST.

I'll probably just do a session variable of an array of all the data and then loop through to match the numbers with the scenario given, verifying _GET.

(bous)

[Edited on June 16, 2007 at 11:49 AM. Reason : ]

6/16/2007 11:41:06 AM

evan
All American
27701 Posts
user info
edit post

set a cookie and store stuff in session vars

or make a hash out of the string and just send that as a var over GET to the page you want, decrypt it, and you're golden

(i like get better than post 'cause it makes prettier URLs, you can do fun stuff like http://website.com/?func=i4ngoerg&buttsecks=yes)

6/18/2007 9:55:47 AM

bous
All American
11215 Posts
user info
edit post

if i set a cookie they can change it, no?

if i set a session var they can't since that's server side.

6/18/2007 10:16:35 AM

 Message Boards » Tech Talk » PHP - Pass _GET variables but make sure no changes Page [1]  
go to top | |
Admin Options : move topic | lock topic

© 2024 by The Wolf Web - All Rights Reserved.
The material located at this site is not endorsed, sponsored or provided by or on behalf of North Carolina State University.
Powered by CrazyWeb v2.38 - our disclaimer.