Dear friends, I am glad to welcome you again to my blog “”. Today we will talk about how to set a password on a WordPress website page, everything is very simple here, but what is it for? I will try to answer these and other questions for you today.

Why put a password on the page?

Sometimes it is necessary to restrict access to certain sections of the site; these sections may contain information for privileged users (often practiced), or access to hidden sections may be paid. The fee can be charged either once or in the form of a subscription fee, for example, once a month. This way you can make a secure website page and provide paid access to your visitors.

Nowadays there are a lot of offers on the Internet where it is proposed to take part in a paid training or purchase a course on the topic of monetizing sites with paid access to certain pages, but you should not buy them. Most likely, you won’t find anything new there, but you will learn how to set a password on a website page and how to change it in this article, completely free of charge.

I think the principle of making money on paid access is clear: set a password, accept payment, send the access password. If this is a subscription fee, then change the password once a month, collect the payment again and send a new password. All this can be automated using the excellent service e-autopay.com, this service is very convenient in terms of accepting payments and automatically sending electronic and physical goods, PIN codes and so on, everything can be configured into a convenient affiliate program, I advise you to pay attention , the service is used by all well-known information businessmen such as Azamat Ushanov, Alexander Borisov and many others. By the way, it is also implemented on the e-autopay.com service.

Now let's find out how to set a password on a WordPress site page. To do this, we need, of course, to first create the desired page, and then go to edit the post and go to the “Publish” tab and click on the “edit” link, see the figure.

Then you will see the following window where you can select visibility, public, private or password protected, and you can also pin the page at the very top on the Home page, but we need a password, select the desired function and set a password for the page, as shown in the figure below.

After all the above steps, all you have to do is publish the page at the right time. In this simple way, you can create pages with a password on your blog and thereby create paid or limited access to various information. For example, on my blog, access to a free course is limited, access can only be obtained after subscribing to this course, after activating the subscription, an access password is sent to your email, everything is very simple and everything is automatic. As you can see, there is nothing complicated about this; you can set passwords on any pages and articles of your site.

Now you know how to put a password on a page or article on a site. I hope this information will bring you benefits and new ideas for making money on your website. As always, I look forward to your questions and comments on this article.

I decided to describe ways to protect part of the site with a password. The topic is actually quite large, so for the first time I will limit myself to php+mysql authorization.

The very first question that usually arises is how to close the directory with administration scripts with a password. In this case, no frills are needed - one or more administrators have the same rights, and personalities rarely change. The easiest way in this situation is to use standard server authorization - put the .htaccess and .htpasswd files and write the necessary parameters in them. A lot has already been written about this, so I won’t say anything particularly new.

I'll add two things. The first is where to put the .htpasswd file. Experimentally, I found out that if, for example, the path to a document with an error message (ErrorDocument) is written relative to the DocumentRoot system variable. But the path to the password file (UserFile) is written relative to ServerRoot. As far as I understand, you cannot put .htpasswd above ServerRoot - "../" is not perceived. All this is done so that you can place a file with passwords, for example, one level above the root directory of the site, so that there is no access to the file from the network at all.

The second is that the script can find out who is opening it and the password: the $PHP_AUTH_USER and $PHP_AUTH_PW variables.

The main disadvantage of this method is that the server cannot block password guessing (after several unsuccessful login attempts, the user is asked to wait an hour or two, and during this time calls from his IP address are ignored). This is written in the official Apache documentation.

Another drawback is the need to rewrite files with passwords when deleting a user or introducing a new one. But if this happens infrequently, this method is quite sufficient, and you won’t have to worry about writing an authorization mechanism.

Automation of authorization

This is necessary not only to simplify work with a large number of users and their high turnover. If you need to keep additional information about users, or you need flexible differentiation of rights, it is better to transfer authorization to the database.

Each page of a closed territory includes a file with the following code:

$result = mysql_query(" SELECT * FROM person WHERE login="". preg_replace("/[^w_-]/","",$PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW). " ""); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm="User area""); header("HTTP/1.0 401 Unauthorized"); print("To log into the user area of ​​the site , you must enter your username and password."); exit(); ); $user_row = mysql_fetch_array($result);

In the first line, all characters except letters, numbers, dashes and underscores are removed from the login. The number of rows received is then checked and only if it is one row is access granted. In other cases, the user will see a window in the browser prompting you to enter a login and password. If the user logged in successfully, we have all the information about him in the $user_row array.

Of course, the example I gave has a number of significant shortcomings. Do not rewrite it one-to-one, so as not to fall victim to password guessing attempts, because
1. there is no protection against selection here
2. if the user table is large, when guessing the password, an attacker will most likely overwhelm the database

And the last method for today is storing encrypted data in cookies.

There is a script for logging in, the rest include code that only allows you to continue actions in a closed area - if the cookies expire or he logs out of there, you will have to return to the login page.

The input script checks the login and password and issues two cookies. In the first - the login, in order to immediately identify the user (in the database, the login field is, of course, unique or even key). The second cookie contains a hash of the login time and password (for completeness of secrecy, I add the letter “Y” to these lines - then it is almost impossible to find the hash :).

All other programs include code that does the following. Makes a request to the database - selects the line with the received login. From this line it takes the “log_time” field and the password and makes a hash from them, as described above. Compares it with what it received, and if they match, issues a new hash cookie, again, from the password, time and letter "Y" and makes a query to the database "UPDATE user SET log_time='...' WHERE login='$ cookie_login'".

if (isset($HTTP_COOKIE_VARS[$cookie_login]) && isset($HTTP_COOKIE_VARS[$cookie_code])) ( $login = $HTTP_COOKIE_VARS[$cookie_login]; $code = $HTTP_COOKIE_VARS[$cookie_code]; $result = mysql_query("SELECT date_format(log_date,"%Y%m%d%H%i%s") as log_date1,pass,uid FROM user WHERE email="$login" AND log_date>"DATE_SUB(NOW(),INTERVAL 15 MINUTE)"" ); if (!mysql_error() && @mysql_num_rows($result)==1) ( $log_time0 = time(); $log_time1 = date("YmdHis", $log_time0); $log_time2 = date("Y-m-d H:i :s", $log_time0); $current_user = mysql_fetch_array($result); if (md5($current_user["pass"].$current_user["log_date1"].$md5letter) == $code) ( mysql_query("UPDATE user SET log_date="$log_time2" WHERE uid=".$current_user["uid"]); setcookie($cookie_code, md5($current_user["pass"].$log_time1.$md5letter), time()+900, $site_path); $auth = true; ) else unset($current_user); ); );

Again, there is no protection here from selection and attack on the server (by the way, here you can write the user’s IP address instead of the letter “Y” - so that, for example, an office neighbor cannot take a file with a cookie and log in from his computer).

Password for the page. Part 2. Recruitment blocking

When I posted this issue last time, they kicked me on the spot, saying that such a block could derail the server.

But first, about rebound blocking. Banalities, but still. A ten-character password consisting of Latin letters and numbers means there are a lot of options. If you guess a password 1,000,000 times per second, it will take several thousand years. But since such gobbledygook is difficult to remember, we often make passwords out of meaningful words. A few years ago, it turned out that most passwords can be guessed using a dictionary of 10,000 words. At one time, a worm (a virus like that) appeared on the network, which climbed Unix servers, using their security holes, and picked up passwords for privileged users using... the Unix system spelling dictionary. There was no need to carry anything!

Each user, until he has entered the correct login and password, is considered an evil hacker. What do we deal with when the user enters something incorrectly?
forgetfulness (for this, decent websites have a “forgot password” form to send this same password to the email entered in the system settings)
pampering (“because I don’t care”)
selecting a password using a dictionary (the probability of a successful selection is high, so you need to close it, especially if the site is of a commercial nature)
DoS attack (in order not to overload the server, you need to minimize the actions that the script will perform in this case)

I thought for a long time about how I could cause an overload on the server if the protection mechanism is based on files. It turned out to be easy (how much it will cost is another question). So, let’s say the server won’t be able to handle it if the script tries to open files for writing 1000 times a second and write data to them. Since after 5 unsuccessful attempts to log in, the user will immediately be denied access (without any data being written to a file), you need to find 200 unique IPs, from which you must contact five times each. It's possible. We hang an html banner with five tags in the banner scroller:

The user instantly makes five requests; the server writes to the file five times (by the way, in some browsers, a window for entering your login and password may pop up). You can make an HTML page with five such pictures, and insert the page itself via an iframe onto the site you are visiting (via an iframe - so that the referer field will not be found. It is unlikely that the support service of a free hosting will deal with such things as digging through log files in search of referrers) . The examples that I gave are, of course, far-fetched, but the very fact that one can take advantage of such a flaw in the system has been proven. By the way, something similar has already happened.

But I’ll still give you this method - I wrote it in vain, or what? By the way, it can be used without much fear for a limited number of addresses (for example, for a company’s local network) by placing a .htaccess file in the directory with the following content:

order deny,allow
deny from all
allow from xxx.xxx.xxx

And here is the program code:

$errors = 0; $fn = "ignore/". preg_replace("[^d.]", "", $REMOTE_ADDR. ".". $HTTP_FORWARDED_FOR); if (is_file($fn)) ( if (filectime($fn)< time()-3600) unlink($fn); else $errors = fread(fopen($fn, "r"), 2); }; if ($errors>5) ( print ("Access is closed. Please come back in an hour."); exit(); ); // here the connection with the database server is established. so as not to touch in vain if the user is immediately “beaten”. $result = mysql_query("SELECT * FROM user WHERE login="". preg_replace("/[^w_-]/", "", $PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW). " ""); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm="secret area""); header("HTTP/1.0 401 Unauthorized"); print ("Authorization required"); fwrite (fopen($fn, "w"), ++$errors); exit(); ); $current_user = mysql_fetch_array($result); mysql_free_result($result); However, it’s a sin to work with files if there is a database. Joke. For failed authorizations, we create a table: CREATE TABLE unauth (username VARCHAR(64) NOT NULL, pass VARCHAR(64) NOT NULL, ip VARCHAR(255), logintime TIMESTAMP) And instead of accessing files, we work with the database. $errors = @mysql_result(mysql_query("SELECT count(username) as false FROM unauth WHERE logintime>DATE_SUB(NOW(),INTERVAL 1 HOUR) AND ip="$REMOTE_ADDR""),0); if (mysql_error()) die(mysql_error()); if ($errors>5) ( print ("Access is closed. Please come back in an hour."); exit(); ); $result = mysql_query("SELECT * FROM user WHERE login="". preg_replace("/[^w_-]/", "", $PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW). " ""); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm="secret area""); header("HTTP/1.0 401 Unauthorized"); print ("Authorization required"); mysql_query ("INSERT INTO unauth (username, pass, ip) VALUES ("$PHP_AUTH_USER", "$PHP_AUTH_PW", "$REMOTE_ADDR $HTTP_X_FORWARDED_FOR")"); exit(); ); $current_user = mysql_fetch_array($result); mysql_free_result($result);

Whether to store old records for statistics or not is a business decision. If anything, they can be deleted by executing the following request before authorization:

DELETE FROM unauth WHERE logintime