I haven't officially started learning PHP, just skimming through a couple tutorials and I have a question. Why would some one choose to use Get vs Post? Why would you ever want the data shown in the url bar? I understand post is used for passwords and important info but I don't understand why you would use get instead of just post all the time?
Thanks for any insight.
$_GET is useful for pages where users are requesting data - such as a search page, and pages that a user might want to bookmark and share with others. Actions that should be readonly.
$_POST is useful for pages where users are "posting" data - such as a signup form. $_POST should be used when you don't want your visitors to be able to bookmark page. Actions that write data.
As prodigitalson added: you may use $_POST or $_GET for any operation, but it is good practice to use them as described above.
If you want people to be able to share the link with their friends...for eg http://example.com/products.php?product_id=12
GET requests are idempotent. POST requests change server state.
This is an HTTP question, not a PHP question.
are you planning to fill your website with forms and buttons on each link?? every link you see in this site is sending GET variables.. maybe your question is related to the "method" attribute in a form, if that's the case, well 90% of the cases post is a better choice
dont worry about the security :) just because you dont see the information in the navigation bar doesnt mean that its secured, watching the information sent by post is only two clicks away ;)
Some times you have to pass params(data) to a script without form submit OR want to share that script to someone. In that case $_GET is useful.
GET method may result in long URLs, and may even exceed some browser and server limits on URL length.
GET can be used for multiply reasons..
If you want to share a URL with your friend, like http://site.com/share.php?id=123 <- Often used.
Its often used to do dynamic actions.
POST is often used when sensetive information should not be shared.
You can look it up on google to learn more =)
Related
I came across a situation where someone wanted me to implement Sorting, Search, record-per-page and pagination through POST request rather than GET.
I tried him to tell why POST is not feasible, Like
User will not be able to bookmark the page
Through POST we cannot maintain paging params when search returns records greater than record per page.
Sorted order will not be maintained when user navigates to next page by clicking page number.
Then he suggested me to keep search, sorting and paging values in cookies for that instance, once user moves to other page we can clear the cookies, or we keep in session
Please help me to decide is this right way of doing the things?
So, I don't want to jump into the middle of your company dispute, but I understand the situation your in and realize that sometimes you need someone on your side.
1). First, POST os NOT for getting, so by definition, he is wrong. If you are not creating anything, you simply do not POST. See here.
2). Your point about not being able to bookmark the page for access later is comletely valid.
3). No. No, no, no. Do not store that stuff in the session or cookies. While it won't harm anything, it's completly unnecessary. It isn't sensitive data, and technically speaking it could work. However, you would only need to do this if you had already broken the first point and used some verb other than GET.
If you are paginating, sorting, etc it is because you have receieved data. You cannot receive information unless you first GET it, right?
First of all you should make him understand where to use GET, and Where to use POST.
I am giving here in short, for detailed information you can ask to google.
GET: Usually used to submitted the search request or any request where user wants to pull the information from the server.
Advantage of GET .
1. page can be bookmarked.
2. page can be reloaded safely.
POST: Used for request where data may be altered or added in database. or page what you don't want someone bookmark.
Advantage of POST.
Name value pair is not shown in URL. So this is plus point for security.
Unlimited number name value pair is passed.
Basically as I mentioned POST is used for destructive action such as creation, editing or deletion.
And for pulling the data we mainly use GET.
and what is the need to put the search param in to cookies, Because as far as I think you are doing all the stuff like sorting or searching on server side, So You will have to pass that in to url every time (or POST body If you follow the path suggested by your Einstein Senior :) ), So no need to fill the cookies space
I hope this will help and he will understand.
Is there a way that I can read the $_POST of a website that I don't own? For example I want to auto fill someone else's form for my users when they go there, so I wanted to reverse engineer their post.
Or is there a way to auto fill a form on someone else's form?
EDIT:
Some people asked what my motives are. I'm working with a group that doesn't have the right to change a website but wants more registration, and I wanted to see if I could remake the form so it was auto-filled to make registration easier.
The short answer is NO, but, you can sniff the HTTP request.
See this question: can-ones-post-request-data-be-sniffed
Basically, if it's a simple form, you don't need to read the post data, you can simply create an identical form with the same action url and set the method to post. You can auto fill this form and send it to a different site.
You could use FireBug or simply the browsers developer tools and analyze the network tab.
You should find all relevant information in the header section.
Browsers are built NOT to allow interaction between different sources, for example an iframe of site1.com inside site2.com can't communicate with JS.
Being able to read $_POST related to another site would be a security disaster. To assist the user the browsers utilize "auto-fill". That's all you get.
If it's a limited amount of peer-sites you may however contact the respective owner of the site and ask them to add support for passing arguments to their login(?) or registration(?) form, for example:
theothersite.com/register.php?email=theEmailYouKnow
By generating this link on YOUR server you get the email to popup on the other site IF implemented by the maintainer of the other site.
I want to implement a system where I want to know where a POST request cam from.
For example: I have a form with a submit button in it. When the User clicks on the submit button it goes to the page. But I want to know the source from where the post request came.
This is the code till now:
<form action="profile.php?id=<?php echo $user->id; ?>" method="post" name="formAdd"><input name="btnAddUser" type="submit" value="Add User"></form>
Should I use a hidden input element? Would that be a good way OR maybe something else?
First of all, there is no reliable way - users can tamper with requests if they want to.
Besides that, there are two ways to get the kind of information you want:
The referer, available via $_SERVER['HTTP_REFERER']: It contains the full URL from which the request came, but some people use extensions/firewalls/etc. that block or even spoof referers
As you suggested, a hidden form element. This always works unless the user actively wants to tamper with the data sent. So that's the preferred way.
The $_SERVER['HTTP_REFERER'] will let you know where the request came from.
More info:
http://php.net/manual/en/reserved.variables.server.php
It really depends on how secure and reliable you need it to be. A hidden form field would work although it means you'd need to add it to every form that points to your processing script. It's also easy to fake if someone wanted to. Alternatively you could use $_SERVER['HTTP_REFERER']. This isn't always reliable - I believe it does depend on what browser you're using but should be good enough in most simple scenarios. Another alternative would be to store something in the session and use that. That's probably the most secure as it's all server-side and can't be tampered with, but it is probably the hardest to implement (not that it's rocket science).
You could save the page in a session variable ($_SESSION["something"] = "page.php"), that is the most secure way, I think, because a hidden input in a form could be changed by the user, and $_SERVER['HTTP_REFERER'] is not always avaliable.
I would use a hidden field where the value="name_of_referring_page".
This way, no matter what the user's settings, firewall, browser, etc you get the info that you want.
i've a jquery script which post/get data to .php script. but i wanna prevent direct access to the php script. for example if the user look at the html source code,they will be able to access the php script directly by copying the url from the js file and i dont want that. how do i prevent users from doing that?? i want the user to use it via the html UI. i've google but found no link on this. however, i did notice that some popular websites are able to do that. how should i go about doing this??
It seems like a simple redirect is what you're looking for here.
Add something like this to the top of your php file. This will prevent the page from being accessed if the proper post has not been made. Of course you'll have to change the post and redirect to content more relevant to your project.
if (!isset($_POST['data'])) {
header('Location: your-redirect-location');
}
You may also be able to redirect based on the $_SERVER['HTTP_REFERER'] variable.
EDIT: I was going to explain this in a comment but it's too long. I should note that this is a simple solution. It will keep people from accidentally accessing your script. It's really difficult to create a 100% secure solution for your issue, and if somebody really wants to access it, they will be able to. If you don't have anything secure in the script in question, this will be fine. Otherwise, you'll have to look for an alternative.
Here is one solution:
<?php
if(isset($_POST["post_var]))
{
//to the code you want to do when the post is made
}
else
{
//do what you want to do when the user views the post page
}
?>
how do i prevent users from doing that?
You can't - all you can do is mitigate the risk people can fiddle with your script. Making sure you have the right HTTP_REFERER and/or POST data are both useful in that regard: a "malicious" user would need more than pointing her browser to the URL.
More techniques can be used here:
using session variables: you might not want users that are not logged in - if applicable - to use the URL.
using a one-time challenge (token): you can place a value in the HTML page and have the JS code send this value along with the POST request. You store this value in the session when it is generated. Checking the POSTed token against the session token guarantees the user has at least "seen" the HTML page before submitting data - this can also be useful to prevent duplicate submissions.
However, remember that anything a browser can do, people can do it as well. All these techniques can prevent the curious from doing harm, but not the malicious.
All you can do is making sure nobody can really harm you, and in this regard, your Ajax URL is no different than any other URL of your site: if it's publicly reachable, it has to be secured using whatever technique you already use elsewhere - sessions, user rights, etc.
After all, why should you care that users use this URL not using a browser ? You might want to think of it in terms of an API call that, incidentally, your page happens to use.
Your problem is similar to and has the same problems as a cross site request forgery.
To reduce your risk, you can check the request method, check the referrer, and check the origin if set. The best way is to have a secret token that was generated on the server that the client transmits back in every request. Since you're dealing with friendly users who have access to your live code, they may be able to debug the script and find the value, but it would only be for one session and would be a real hassle.
I'm making a register page, signup.php, and basically what I want it to do is check for errors and if there are none, redirect to register.php. That is fine and whatnot, but register.php is the page where the actual account is made (e.g. mySQL query). Of course, in order to do that, I actually need the params gathered form signup.php. I was wondering if I could do something like this..
header("Location: register.php, TYPE: POST, PARAMS: {user,pass,email}")
Obviously I can not use $_GET as I am transmitting sensitive data (e.g. passwords).
Any ideas/suggestions?
EDIT: Thank you all for your answers. I am now storing the parameters in a $_SESSION variable.
I see no point in such redirect.
Why not to post right away to register.php?
And then check for errors and save data in database in the same register.php?
without any redirects
No, you can't, and such data would be just as insecure to any determined attacker.
Store the data in a session variable for use in the next page.
Even if this is possible, you will hit another brick wall - the implementation of redirects in the popular browsers. While the standard requires, that it asks the user if a post is redirected, all popular browsers simply interpret the redirect as a GET. In short: you can't redirect a POST that way, you'll have to find another way without a round trip to the client, or use GET.
Also, you should be aware that unless your requests are done via https, both GET and POST will present the sensitive information to any listener, as POST simply buts the query string into the http request and not the url. Security wise, both are the same.
You could store them in the $_SESSION and refer to those in the register.php page, doing some checking to make sure someone has actually filled out the information and didn't just navigate to it.