The design method of the failure of the URL access once

For example, a URL like the following:

https://foo.com/? timestamp= time &nonce= random string &sign = signature

There are several ways I can think of this:
1, the Storage database: The first visit, the URL of the library, the second visit, check the library;
2, save the session, the first deposit, after the check;
3, deposit Redis, Mencache, etc., first deposit, after check;
Although the above methods can meet the requirements, but each time must be saved and then checked, the data is small, if there are tens of millions, hundreds of billions of data? Do you want to check this? Is there a good way out?

I'm thinking about whether I can design an algorithm based on the rules of the URL to verify that the URL has been accessed, even if the data is stored with little data, rather than the entire URL.

Reply content:

For example, a URL like the following:

https://foo.com/? timestamp= time &nonce= random string &sign = signature

There are several ways I can think of this:
1, the Storage database: The first visit, the URL of the library, the second visit, check the library;
2, save the session, the first deposit, after the check;
3, deposit Redis, Mencache, etc., first deposit, after check;
Although the above methods can meet the requirements, but each time must be saved and then checked, the data is small, if there are tens of millions, hundreds of billions of data? Do you want to check this? Is there a good way out?

I'm thinking about whether I can design an algorithm based on the rules of the URL to verify that the URL has been accessed, even if the data is stored with little data, rather than the entire URL.

You always have to store the "URL has access" information in the background, this point can not run, by algorithmic means can not eliminate the problem.

But the easy part of this requirement is that there is no connection between the request and the request, and you can use any method to divide the table and the library. For example, a URL is used as a bucket basis (note) to distribute database requests directly into the DB cluster. Tens of millions of billions is also able to do.

The real difficulty of this requirement lies in atomicity, that is, when two requests arrive at the server simultaneously, how to resist the time difference between two transactions and the database, resulting in inconsistent data.

However, this solution can be achieved by the locking mechanism of the table + database. Sub-table sub-Library here at the same time to undertake the (1) the number of requests to share the pressure (2) to share the performance of the lock-up pressure two role.

Note 1: Of course, in practice, to the URL to do a normalization, to avoid ?v1=1&v2=2 and ?v2=2&v1=1 be judged as a different URL, such as oolong conditions occur.

Note 2: In fact, according to business logic, with a single valid index string/token/nonce key (whatever it is called, as you like) to do key is the best, save the trouble of handling the URL.

Note 3: In general, the database cluster suite will automatically assume the split-bucket algorithm without manual writing.

The URL itself does not change, the server side must have something change
So to strictly guarantee 1 times, save this thing feel is not escape

Now you don't have to save the entire URL, you can save the nonce.

Plus temporary tokens?

Do not need the entire URL, in fact, is to visit your Web page requires a password, and password can only be used once.
In your own way, the session is not a global one, so you can only use the database or Redis two options.

It's impossible to understand why the URL is invalidated ...

Regardless of the method stored above, the server does not store how it can be done to

Random string takes a bit longer. The URL has a valid time and then stores those URLs as valid. Can be stored in the database, scheduled + Access after the cleanup database.
General Registered user Mailbox Verification/Change password that's it.
From a probabilistic standpoint, a malicious attacker who has not obtained a legitimate random number and sign will not be able to traverse all possibilities within the effective time. If you add some limit to the number of IP attempts, it is safe to do so.

If you are not trying to verify that a URL can be accessed at most once, nonce set it to an incremented number.

Write a cookie after you have visited

Millisecond timestamp plus random string hash value as key effective time to cache any content (simple can be like 1), the time stamp to determine the validity time, and then verify that the cache exists, the two parameters must be transmitted

Are you primarily not the problem of data volume?
Well, for! What! You! Save data to a user's local terminal without a cookie

Through the timestamp to do a lot of, generally timestamp more than a certain range as an invalid URL, so the nonce warehousing or redis, a period of time after the failure is good, because will first use timestamp to determine whether the request expires, Then use the nonce to determine whether to repeat the request. The timestamp range is 30 seconds or so, basically enough.

