Работа с формами

Одно из главнейших достоинств PHP - то, как он работает с формами HTML. Здесь основным является то, что каждый элемент формы автоматически становится доступным вашим программам на PHP. Для подробной информации об использовании форм в PHP читайте раздел Переменные из внешних источников. Вот пример формы HTML:

Пример #1 Простейшая форма HTML

<form action="action.php" method="post">
 <p>Ваше имя: <input type="text" name="name" /></p>
 <p>Ваш возраст: <input type="text" name="age" /></p>
 <p><input type="submit" /></p>
</form>

В этой форме нет ничего особенного. Это обычная форма HTML без каких-либо специальных тегов. Когда пользователь заполнит форму и нажмет кнопку отправки, будет вызвана страница action.php. В этом файле может быть что-то вроде:

Пример #2 Выводим данные формы

Здравствуйте, <?php echo htmlspecialchars($_POST['name']); ?>.
Вам <?php echo (int)$_POST['age']; ?> лет.

Пример вывода данной программы:

Здравствуйте, Сергей.
Вам 30 лет.

Если не принимать во внимание куски кода с htmlspecialchars() и (int), принцип работы данного кода должен быть прост и понятен. htmlspecialchars() обеспечивает правильную кодировку "особых" HTML-символов так, чтобы вредоносный HTML или Javascript не был вставлен на вашу страницу. Поле age, о котором нам известно, что оно должно быть число, мы можем просто преобразовать в integer, что автоматически избавит нас от нежелательных символов. PHP также может сделать это автоматически с помощью расширения filter. Переменные $_POST['name'] и $_POST['age'] автоматически установлены для вас средствами PHP. Ранее мы использовали суперглобальную переменную $_SERVER, здесь же мы точно так же используем суперглобальную переменную $_POST, которая содержит все POST-данные. Заметим, что метод отправки (method) нашей формы - POST. Если бы мы использовали метод GET, то информация нашей формы была бы в суперглобальной переменной $_GET. Кроме этого, можно использовать переменную $_REQUEST, если источник данных не имеет значения. Эта переменная содержит смесь данных GET, POST, COOKIE.

В PHP можно также работать и с XForms, хотя вы найдете работу с обычными HTML-формами довольно комфортной уже через некоторое время. Несмотря на то, что работа с XForms не для новичков, они могут показаться вам интересными. В разделе возможностей PHP у нас также есть короткое введение в обработку данных из XForms.

add a note add a note

User Contributed Notes 6 notes

up
172
sethg at ropine dot com
14 years ago
According to the HTTP specification, you should use the POST method when you're using the form to change the state of something on the server end. For example, if a page has a form to allow users to add their own comments, like this page here, the form should use POST. If you click "Reload" or "Refresh" on a page that you reached through a POST, it's almost always an error -- you shouldn't be posting the same comment twice -- which is why these pages aren't bookmarked or cached.

You should use the GET method when your form is, well, getting something off the server and not actually changing anything.  For example, the form for a search engine should use GET, since searching a Web site should not be changing anything that the client might care about, and bookmarking or caching the results of a search-engine query is just as useful as bookmarking or caching a static HTML page.
up
2
Toasty_Pallate
23 days ago
It is worth noting that GET request parameters can be cached while POST request parameters are not. Meaning that if a password is GETted it is stored at various points on the way to the server (Your browser and anyone it's sharing info with, the people manning the firewall at the Org that is receiving the GET, the server logs, etc.)

While it is true that HTTPS encrypts the URL and GET request parameters, nothing guarantees that there is not a Web Application Firewall (that decrypts all traffic going into the Org for inspection) and is logging user info or that one will be implemented in the future at your org. Logs in plain-text are (hopefully) a LOT easier to compromise than a database of hashed passwords.

So if you're managing sensitive information, it's best to use POST.
up
75
Johann Gomes (johanngomes at gmail dot com)
7 years ago
Also, don't ever use GET method in a form that capture passwords and other things that are meant to be hidden.
up
12
nucc1
6 months ago
worth clarifying:

POST is not more secure than GET.

The reasons for choosing GET vs POST involve various factors such as intent of the request (are you "submitting" information?), the size of the request (there are limits to how long a URL can be, and GET parameters are sent in the URL), and how easily you want the Action to be shareable -- Example, Google Searches are GET because it makes it easy to copy and share the search query with someone else simply by sharing the URL.

Security is only a consideration here due to the fact that a GET is easier to share than a POST. Example: you don't want a password to be sent by GET, because the user might share the resulting URL and inadvertently expose their password.

However, a GET and a POST are equally easy to intercept by a well-placed malicious person if you don't deploy TLS/SSL to protect the network connection itself.

All Forms sent over HTTP (usually port 80) are insecure, and today (2017), there aren't many good reasons for a public website to not be using HTTPS (which is basically HTTP + Transport Layer Security).

As a bonus, if you use TLS  you minimise the risk of your users getting code (ADs) injected into your traffic that wasn't put there by you.
up
-87
wojciech dot fornal at gmail dot com
2 years ago
@sethg at ropine dot com

You're partially right. For many people, the difference between POST/GET is about whether data is sent as a URL query (GET) or as a HTTP request payload together with headers (POST) and in most cases it is used so with regards to that.

In case of forms the difference between GET and POST has more to do with convenience and the fact that both methods fit to certain use cases and not with the fact whether a some resource is created/changed on the server or not (eg. login forms use POST method mainly to not expose sensitive data in URL etc.). It all depends on the back-end implementation what really happens after GET or POST request is received.

GET is good if you want the request to be cacheable and/or bookmarkable. In most HTML form cases though, POST seems always better, especially when we deal with long data (eg. forum post).

To be strict about HTTP verbs, POST verb usually means creation of new resource while to update an existing resource, the PUT method is used (not applicable in case of HTML forms except some additional hidden "method" form fields).

Those who are not familiar with HTTP verbs shall dive into HTTP specs (RFC 2616, section "9 Method Definitions")  and read a bit about REST.
up
-131
Andy
5 years ago
Just a reminder about security: the chosen HTTP request verb (e.g. POST, GET) does not necessarily make the request "secure". Any information that is not transmitted over an encrypted channel (using SSL, i.e. HTTPS) is transmitted in plan text.

For secure transport of sensitive/private information over HTTP consider using SSL as this prevents eve's dropping of the information transmitted over HTTP.

[Edited by googleguy@php.net for clarity]
To Top