In the past, IDs were directly transmitted as get parameters at the front end, such as a.com? If the user finds this rule, he can change 16 to 17, 18, and 19 to view the data of each user, so I want to ask how you solve this problem? The requirement is not to say that the request does not allow... in the past, IDs were directly passed as get parameters on the front end, for example
a.com?uid=16If you find this rule, you only need to change 16 to 17, 18, 19, and so on to view the data of each user. so I want to ask you how to solve this problem?
The requirement does not mean that users are not allowed to view other users' information, but can view all of them. Why is there such a demand? This is like a number. if there is a number, you can find the person without a number. it is also difficult to find the person by credential stuffing or luck. On Youku, Tudou, and site B, all video websites do not directly display the video id on the address bar and are encrypted. (If the video site database does not require continuous IDs, I did not know the database of the above website)
The requirement is that encryption and decryption are fast and difficult to crack. (The former takes precedence)
Reply content:
In the past, IDs were directly transmitted as get parameters on the front end, for examplea.com?uid=16If you find this rule, you only need to change 16 to 17, 18, 19, and so on to view the data of each user. so I want to ask you how to solve this problem?
The requirement does not mean that users are not allowed to view other users' information, but can view all of them. Why is there such a demand? This is like a number. if there is a number, you can find the person without a number. it is also difficult to find the person by credential stuffing or luck. On Youku, Tudou, and site B, all video websites do not directly display the video id on the address bar and are encrypted. (If the video site database does not require continuous IDs, I did not know the database of the above website)
The requirement is that encryption and decryption are fast and difficult to crack. (The former takes precedence)
Yes, if your purpose isPrevents users from viewing data of other usersSo your thinking is somewhat biased.
What you should do is perform authentication on the backend instead of encrypting the uid. For example, the currently logged-on user isuid=16When the requesta.com?uid=17(Or other non-16 pages), the backend should be able to determine that he does not have the permission and give the corresponding response (such as outputting a blank page or directly throwing 403 or so ).
As for how to implement authentication, simply record the uid of the logged-on user in$_SESSION['uid']When each request is made$_GET['uid'] == $_SESSION['uid']True or not.
Supplement:<
The subject updated the question and said that anyone who needs to see the user information only wanteduidHide. In this case, I add a field to the user table.openidAnd add it to the index. you can useuid,UNIX timestamp,Random strings of several lengthsAnd then passmd5()A type of function is generated into a uniqueopenidWhen the information is publicly availableopenidTo retrieve data.
<
If you insist on using encryption, you can search for it on the internet. There are already many mature solutions available.PHP encryption and decryptionFor keyword search in Google, the first page is almost all what you want. for example, the following code is taken from the first article in the search result. you can refer to it (I did not perform a test ).
Source: http://jerry17768java.blogspo...
Hash some + random some
I think you should add the permission judgment function, such as identifying users based on cookies.
OpenSSL AES can be used for encryption/decryption: