Создание и / или проверка лицензионных ключей для App Engine для закрытой бета-версии

Question

Я выпущу свое приложение GAE через несколько месяцев в закрытом бета-состоянии, так что его смогут использовать лишь несколько пользователей, и я получу некоторую дату и знаю, где и как его улучшить.Моя идея состояла в том, что я использую систему ключей, чтобы позволить им получить доступ к приложению.

Что я хочу сделать:

Я хочу сгенерировать удар ключей и сохранитьих с датастором.Когда пользователь заходит в приложение в первый раз, он входит в свою учетную запись Google и должен ввести ключ для активации своей учетной записи.

Мой вопрос:

Мойпредыдущее программное обеспечение не требовало таких лицензионных ключей или аналогичных, так что это новая область для меня.Как вы думаете, это хороший способ реализовать закрытую бета-версию?Моя вторая идея состояла в том, чтобы сгенерировать кучу ключей и проверить их с помощью системы, как это делает другое популярное программное обеспечение, но я думаю, что в этом нет необходимости, и я не хочу избегать того, что кто-то может сделать key-gen.Моим предложением было бы просто сгенерировать, сохранить, затем проверить ключ, если он существует в хранилище данных, настроить его на использование и активировать учетную запись.

Как я могу сгенерировать много действительных и легко добавить больше (без дубликатов)) ключи.Я благодарен за каждый опыт и предложение.

Answer 1

В качестве дополнения к предложению Эшли, если вы хотите сгенерировать более короткие и / или более простые для ввода идентификаторов, вы можете сгенерировать некоторые случайные данные и кодировать их с помощью base32:

base64.b32encode(os.urandom(8)).strip('=')

Сделайте его более читабельным, вставив дефисы:

'-'.join(base64.b32encode(os.urandom(8)).strip('=')[5*x:5*(x+1)] for x in range(3))

Это дает вам коды, подобные следующим:

'C6ZVG-NJ6KA-CWE'

Затем просто сохраните результат в хранилище данных и раздайте его пользователям. Я бы посоветовал хранить код без дефисов и удалять эти символы перед проверкой базы данных. Если вы хотите стать действительно модным, алфавит base32 выбирается так, чтобы избегать похожих символов; Вы можете заменить эти символы перед проверкой, чтобы учесть опечатки.

8 байтов случайных данных дают 2 ^ 64 возможных кодов приглашения; если вы раздадите, скажем, 2 ^ 16 (65 536) из них, злоумышленнику все равно придется попробовать 2 ^ 48 (около 300 триллионов) кодов, чтобы найти правильный. Если хотите, вы можете сократить свои коды за счет сокращения пространства поиска.

Answer 2

Я использую UUID для генерации случайных ключей:

UUID.randomUUID().toString().replace("-", "");

Из документов: «UUID генерируется с использованием криптографически стойкого генератора псевдослучайных чисел».

Создайте длинный список из них в хранилище данных, а затем, когда пользователь получит что-то вроде: yourapp.com/betainvite/blahblahkey, вы можете просто проверить, находится ли ключ в таблице и является ли его свойство rsvp пустым ( или уже установлен на дату, когда он был использован, и в этом случае вы отказываете в приглашении).

Вы также можете хранить ключ для своего Пользователя, чтобы вы могли узнать, кто и когда использовал каждый из них.

Также хорошей идеей является сохранение приглашенной даты на клавишах, тогда, когда вы используете каждую из них, вы можете пометить ее как приглашенную, чтобы вы не дважды приглашали людей.