Стратегии аутентификации пользователей одно время без предобщего идентификатора
Если вы не хотите настраивать схему репликации, почему бы просто не использовать (2 или 3) задания cron, дамп local / dump remote / update remote с локальным дампом. И нет, это не лучший способ сделать это, но это работает ...
С помощью just (2) выведите дамп local / update remote с помощью локального дампа, запускайте ежедневно @ 1:00 AM dump и!: 15AM update
0 1 * * * mysqldump --host="localhost" --user="user" --password="password" database_name > backup_name.sql
15 1 * * * mysql --host="remote_host" --user="user" --password="password" --port="3306" database_name < backup_name.sql
4 ответа
Why does it need to be a hash in particular? Just put the new user's username as part of the link, and randomly generate an authentication token of whatever length you want, and store that in the database, linked to their username, until they authenticate.
So the link they get in the email is something like:
http://domain.com/confirm.php?user=Chad&t=AB14CD05
It really doesn't matter if there are any collisions, it's a fairly low risk event anyway. What could go wrong anyway, someone else could... confirm their email address for them? What are you concerned about? Perhaps if you explain the whole process in a little more detail, I'd understand your requirements better.
Существует множество различных алгоритмов хеширования. Вы можете посмотреть по этой ссылке, чтобы увидеть, будет ли работать лучше для вас, так как вам не нужен безопасный хеш. Вы также можете посмотреть, как SSL lib генерирует хэш md4 из 8 символов.
Why not just assign a random 64-bit number to send with the user's id. Take the 64-bit number, break it into 5-bit chunks, and use each 5-bit chunk to index into a 32-character alphabet: 23456789ABCDEFGHJKLMNPQRSTUVWXYZ (conveniently omitting 01IO). With a 64-bit number and 5-bits/code (except the last one) you get a 13 character slug to use to identify the user. You could pad it with 2 random characters to give 3 groups of 5 characters if you wanted.
Make the id and the slug part of the login url. Check the value of the slug stored with the id in the database to make sure they are the same. I think for most purposes this would be a large enough value to make it extremely hard to guess -- the number is random after all -- which slug goes with which user id. Using a cryptographically strong random number generator, I would think it would be highly unlikely that you'd even get repeat numbers for any of your users.
It might look like:
http://example.com/activate?userid=bgates&validate=GY45M-RHQBN-32GYM
Using a hash of known values might actually make it easier for someone to guess the correct code than using a random number. Using a hash one only has to guess which bits you're using and run them through various hash algorithms. If someone is able to piece these together, say given a few examples and enough time to try various combinations, then all they have to do to crack someone's code is determine the (probably) commonly known attributes for a given person and use those to impersonate them and create an account. With a strong random number assigned to each individual they're only left with a brute force attack.
Ознакомьтесь с gperf .
GNU gperf - идеальная хеш-функция генератор. Для данного списка строки, он создает хеш-функцию и хеш-таблица в форме C или C ++ код для поиска значения в зависимости от во входной строке. Хеш-функция идеально, что означает, что хеш таблица не имеет коллизий, а хеш для поиска по таблице нужна одна строка comparison only.
And also CMPH - C Minimal Perfect Hashing Library
There are several related SO questions: