POST without submit

[zester]

HI all
I would like to pass variables to the next page without them showing up in the URL like you do with POST in a form. My problem is that the page I that will be sending the variables from dose not have a form on it so I cannot send them with POST command. So is there a way to pass variable with hyper link, or on a button press, that hides the variables like POST.

 

[TechAsh]

You could use hidden fields in a form, and then the visitor will need to click the submit button to move onto the next page.

Something like:

<FORM method="POST" action="nextpage.php">
<INPUT type="hidden" name="something" value="<? $avariable; ?>">
<INPUT type="submit" value="Next ->">
</FORM>

 

[blu3fire]

or use JavaScript hyperlink isntead of button

<a href="javascript:document.formnamehere.submit()">CLICK HERE</a>

 

[woiwky]

Personally I would just put the data in the user's session and remove it in the next page. That's a lot easier than having to generate it in the html in my opinion. You could just use:

Page 1:

session_start();
$_SESSION['name'] = 'value';

Page 2:

session_start();
$value = $_SESSION['name'];
unset($_SESSION['name']);

This also means that you don't need to generate more html for every link to a page that you want the use the data in.

By the way, phpasks, what's up with you copying the code/answer people posted before you? You're just restating what's already been said, which is basically spam.

 

[zester]

I was thinking of using sessions to pass the data but someone told me not to use them. He said it would makes your website unsecure unless you are very good at coding. Is this true?

 

[konekt]

I was thinking of using sessions to pass the data but someone told me not to use them. He said it would makes your website unsecure unless you are very good at coding. Is this true?

Not particularly true, at least not in the sense that it does not add a significantly extra shaky security then any other methods that introduce dynamic, slightly public, methods (i.e. POST).


You could also use cookies.

 

[marshian]

Sessions are more secure than cookies, if that really matters for you. A user can edit/delete cookies, but he can only delete sessions.
EDIT: I mean, he can delete the cookie that remembers his session, nothing else

 

[woiwky]

I was thinking of using sessions to pass the data but someone told me not to use them. He said it would makes your website unsecure unless you are very good at coding. Is this true?

The only more secure way to store the data is to have the user login and store it in the database. But even then, unless you want to make people login for every page they access, you need a way to store who that person is.

Sessions are the most secure way to store temporary data without decreasing your site's usability. The data is stored out of the web root directory(at least it *should* be), which means people can't even view it.

 

[VPmase]

Even if you were going to use sessions I suggest you create/use some sort of encryption/decryption system so it is secure.

 

[marshian]

Even if you were going to use sessions I suggest you create/use some sort of encryption/decryption system so it is secure.

Why would it be required? Session data is stored on the server, under a session name. The user only has the session name, so he can't really compromise any data... (You can hijack sessions, but you could solve this by storing the users IP with the session information. (If the stored ip and the user's ip don't match, destroy the session and make the user verify himself again.))

 

[woiwky]

If someone manages to hack your server, then them looking at your sessions is the least of your worries. Like marshian said, their only real flaw is that they can be hijacked. However, some ISP's randomly assign new IP's to their users or put multiple people under the same IP, so comparing IP's isn't perfect. You could call session_regenerate_id(true); on each page to invalidate the old session and give the user a new id, but even that has flaws.

There really is no perfect security. Use SSL and have people revalidate themselves for the very sensitive stuff, but for everything else sessions are secure enough.

 

[marshian]

If someone manages to hack your server, then them looking at your sessions is the least of your worries. Like marshian said, their only real flaw is that they can be hijacked. However, some ISP's randomly assign new IP's to their users or put multiple people under the same IP, so comparing IP's isn't perfect. You could call session_regenerate_id(true); on each page to invalidate the old session and give the user a new id, but even that has flaws.

There really is no perfect security. Use SSL and have people revalidate themselves for the very sensitive stuff, but for everything else sessions are secure enough.

Still, if you have 10 people on the same IP, it's a very small chance one of them is attempting to hack another. And dynamic IP's only change if the user goes offline and back online, if I'm not mistaking, an IP can't change as long as there is a connection. And as sessions stop when the user closes his browser, it's not likely to happen the user gets a new IP adress while he's doing whatever you're making that has to be so secure... It's slightly more secure than normal sessions, but still no guarantees... But add the session_regenerate_id(true);-thingie and it's a bit more secure again... You can't have perfect security, but you can make your stuff secure enough with just a lot of small things.

 

[woiwky]

Still, if you have 10 people on the same IP, it's a very small chance one of them is attempting to hack another. And dynamic IP's only change if the user goes offline and back online, if I'm not mistaking, an IP can't change as long as there is a connection.

You might not have heard of or know much about AOL since you're in Belgium. But it's not uncommon for an AOL user to get a different IP for *each* page request. I'm not sure if there are other ISP's in the world which have a similar system, but I made that statement about IP's subject to random change with AOL in mind.

 

[marshian]

You might not have heard of or know much about AOL since you're in Belgium. But it's not uncommon for an AOL user to get a different IP for *each* page request. I'm not sure if there are other ISP's in the world which have a similar system, but I made that statement about IP's subject to random change with AOL in mind.

No, indeed, I had never heard of such a system
Looks like it's safe for the user, but a pain for us... :nuts:

 

[cowctcat]

you could use:

$_SERVER['HTTP_USER_AGENT']

to check for something like that ghastly AOL:fart:

EDIT:
I fixed the spelling in the title of the thread for you

 

[jspcodes]

HI all
I would like to pass variables to the next page without them showing up in the URL like you do with POST in a form. My problem is that the page I that will be sending the variables from dose not have a form on it so I cannot send them with POST command. So is there a way to pass variable with hyper link, or on a button press, that hides the variables like POST.

Session variables should be used for important things like userid which is needed for all pages and hence it can be used as session variable. But for small purposes $_REQUEST['variable'] is enough

example

http://yoursite.com/page1?name=somename

in page1

<?php echo $_REQUEST['somename']; ?>

It will print as some name

I have used this in my site http://jspcodes.elementfx.com

 

[marshian]

without them showing up in the URL
So why are you telling hem exactly what he does not want to hear?

 

[freecrm]

Why would it be required? Session data is stored on the server, under a session name. The user only has the session name, so he can't really compromise any data... (You can hijack sessions, but you could solve this by storing the users IP with the session information. (If the stored ip and the user's ip don't match, destroy the session and make the user verify himself again.))

Good idea - I hadn't thought about this problem. I already have a sniffer script that log visitror paths but haven't yet stored it as a session variable.

How easy is it to hijack sessions?

Can you then access any Session variables such as $MM_Username or $MM_UserGroup?

 

[marshian]

Good idea - I hadn't thought about this problem. I already have a sniffer script that log visitror paths but haven't yet stored it as a session variable.

How easy is it to hijack sessions?

Can you then access any Session variables such as $MM_Username or $MM_UserGroup?

If you manage to find out the ID of another session, it's very easy to edit your cookie and make the server beleive you are the user which has that specific session assigned. But if you manage to do that, you cannot access the session directly, I mean it's impossible for the user to see the actual session data. That person can only see webpages that were intended for somebody else. So when you make a site, don't just show all info you have on that person. Just require them to enter their password again for each page which has (for example) the ability to change their password, their personal contact information, ...

 

[GBH187]

Easy solution

Wrap the page in a frame

url will remain hidden from the end user

If you want a more secure way to do it, Create a form, use a hidden field and submit it like a normal person