Leeching is A service provided by website A, such as downloading music, software, and movies. Website B shares the benefits and directly references the link of website. The consequence is that website A provides services, but it has been used by website B to provide gifts. website A's servers, bandwidth, and other resources have been stolen, but it has not obtained the corresponding click rate, popularity, and advertising revenue.
One simple way to prevent leeching is to use dynamic links. For the same resource, the link is not fixed at different times or different users. You can only log on to the website to obtain the current link. Instead of saving the link, you can continue to use it. This kind of dynamics can be one-time or time-band.
For resource S, if there is a user request, a unique identifier address is generated by using a function F, such as MD5, SHA1, and other hash functions based on the time, user, IP, and other variables, provided to users. The server stores the identifier, time, user, IP address, actual address, and other relationships in the database. The user uses this identifier to download resources to the server. The server uses this identifier to find the actual address and timestamp of the resource. If it does not expire, It maps the actual resource address to the temporary address, then you can download or establish a connection. If the tag does not exist or expires, the user cannot download the resource and must obtain a new temporary address.
The three addresses are mapped to each other. The page address is> the temporary resource address> the actual resource address. To obtain the actual address, you must start from the home page (the latter from the homepage of a subclass) to obtain the actual resources step by step.
This has some effect on Anti-leech protection. For example, if Site B attempts to steal A, it is relatively difficult. You even need to simulate the actual operation for this purpose.