Пусть пользователь зашел на сайт и купил месячную подписку на мою программу. Подписка — это файл с лицензией, доступный по ссылке или пришедший на почту в аттаче.

Вопрос — как лучше организовать работу с этими файлами?

Например, пользователь скачивает этот файл куда-то и потом в программе указывает путь к нему. Но ведь скачается во временную папку скорее всего, может удалиться случайно. Или например пользователь купил очередную подписку за пару дней до истечения предыдущей, и новый файл перетрет текущую лицензию. Заводить папку-хранилище лицензий и проверять все подряд? Но тогда тяжелее определить проблемы.

В общем, понятно что всё это можно быстренько наколхозить. Но хочется узнать реальный опыт тех, что уже собрал все грабли.

Как у вас проходит процесс от получения пользователем файла с лицензией до проверки ее в программе?

Здравствуйте, Basil2, Вы писали:

B>Как у вас проходит процесс от получения пользователем файла с лицензией до проверки ее в программе?

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

Здравствуйте, Basil2, Вы писали:

B>Как у вас проходит процесс от получения пользователем файла с лицензией до проверки ее в программе?

Приходит файл по почте, и дальше пользователь может:
— Либо сохранить его куда-то и потом в программе указать, куда сохранил
— Либо сохранить в папку с программой, и потом при старте программа его подхватит по маске LICENSE*.DAT

По опыту — у 50% не получается сделать ни то, ни другое, т.к. они не знают, как сохранять файлы. Надо добавить еще возможность даблкликнуть по файлу лицензии, и добавить возможность скопипастить содержимое файла лицензии (это BASE64, т.е. текст) в программу. Но все руки не доходят сделать.

P.S. После предоставления программе тем или иным способом ключа программа лОжит этот ключ в свое собственное хранилице ключей. Т.е. то, что указали путь к временному файлу — неважно: после прочтения файла файл уже не нужен.

Здравствуйте, Sharowarsheg, Вы писали:

S>Нет файла, есть ключ. Пользователь вводит ключ, ключ хранится в реестре, при каждом запуске запрос на сервер "слышь, сервер, а чо ключ?" и сервер отвечает, что за ключ и что с ним делать. Вся база с характеристиками ключей на сервере, сами ключи — просто длинные случайные числа.

А как быть с корпоративным пользователем, у которого компьютер в закрытой внутренней сети предприятия? А меж тем, это самые "вкусные" пользователи.

G>А как быть с корпоративным пользователем, у которого компьютер в закрытой внутренней сети предприятия? А меж тем, это самые "вкусные" пользователи.

Можно использовать floating лицензии, когда компания покупает, условно, 15 лицензий и могут пользоваться продуктом на 15 любых компьютерах одновременно. При этом они сами у себя поднимают лицензионный сервер внутри корпоративной сети. Подробнее можно посмотреть на примере LimeLM тут — https://wyday.com/limelm/help/licensing-types/#floating.

Здравствуйте, Grizzli, Вы писали:

S>>Нет файла, есть ключ. Пользователь вводит ключ, ключ хранится в реестре, при каждом запуске запрос на сервер "слышь, сервер, а чо ключ?" и сервер отвечает, что за ключ и что с ним делать. Вся база с характеристиками ключей на сервере, сами ключи — просто длинные случайные числа.

G>А как быть с корпоративным пользователем, у которого компьютер в закрытой внутренней сети предприятия? А меж тем, это самые "вкусные" пользователи.

Я говорю, пусть дырку пробивают себе в файрволе. А если не хотят, пусть идут к конкуренту. У меня всё равно код на сервере исполняется частично, и я никаких лицензионных серверов никому не дам поднимать у себя.

Здравствуйте, Sharowarsheg, Вы писали:

S>Я говорю, пусть дырку пробивают себе в файрволе. А если не хотят, пусть идут к конкуренту. У меня всё равно код на сервере исполняется частично, и я никаких лицензионных серверов никому не дам поднимать у себя.

Ну, это сразу минус весь крупный корпоратив.

Все что остается — малый бизнес да домашний пользователь.

Здравствуйте, Grizzli, Вы писали:

S>>Я говорю, пусть дырку пробивают себе в файрволе. А если не хотят, пусть идут к конкуренту. У меня всё равно код на сервере исполняется частично, и я никаких лицензионных серверов никому не дам поднимать у себя.

G>Ну, это сразу минус весь крупный корпоратив.
G>Все что остается — малый бизнес да домашний пользователь.

Их зато миллионы, и с ними никакой мороки. Ценность крупного корпоратива, на мой вкус, сильно преувеличена. Хотя это зависит от того, что продавать, конечно.

Здравствуйте, Sharowarsheg, Вы писали:

S>Их зато миллионы, и с ними никакой мороки. Ценность крупного корпоратива, на мой вкус, сильно преувеличена. Хотя это зависит от того, что продавать, конечно.

Да, с ними никакой мороки, т.к. им нафиг не сдалось за что-то платить.

Здравствуйте, Grizzli, Вы писали:

S>>Их зато миллионы, и с ними никакой мороки. Ценность крупного корпоратива, на мой вкус, сильно преувеличена. Хотя это зависит от того, что продавать, конечно.

G>Да, с ними никакой мороки, т.к. им нафиг не сдалось за что-то платить.

Ну это опять же, смотря что ты продаёшь.

Здравствуйте, Sharowarsheg, Вы писали:

B>>Как у вас проходит процесс от получения пользователем файла с лицензией до проверки ее в программе?

S>Нет файла, есть ключ. Пользователь вводит ключ, ключ хранится в реестре, при каждом запуске запрос на сервер "слышь, сервер, а чо ключ?" и сервер отвечает, что за ключ и что с ним делать. Вся база с характеристиками ключей на сервере, сами ключи — просто длинные случайные числа.

Разумно, но у меня вся задумка была в том, чтобы не делать свой сервер

Ключ да удобнее (его можно копипастнуть), но у меня регистратор генерит именно файл. Хотя там небольшой xml, в принципе можно предложить и копипастнуть

Здравствуйте, Basil2, Вы писали:

S>>Нет файла, есть ключ. Пользователь вводит ключ, ключ хранится в реестре, при каждом запуске запрос на сервер "слышь, сервер, а чо ключ?" и сервер отвечает, что за ключ и что с ним делать. Вся база с характеристиками ключей на сервере, сами ключи — просто длинные случайные числа.

B>Разумно, но у меня вся задумка была в том, чтобы не делать свой сервер

B>Ключ да удобнее (его можно копипастнуть), но у меня регистратор генерит именно файл. Хотя там небольшой xml, в принципе можно предложить и копипастнуть

Логика работы с ключами, типа, это подписка или нет, она истекла или нет, какие фичи включены в лицензию (если у тебя есть опции за деньги), и так далее, её всё равно писать. Логика хранения ключей и перезаписи (или не перезаписи) одних другими, её тоже писать. С одной стороны, добавляется 300 строк клиента-сервера с файловером и обработкой ошибок, а с другой стороны возникает гибкость некая, с отвязкой от регистраторов, можно отзывать ключи, и всякие мелкие прелести. Я нашёл самым трудным политический вопрос, чтобы научиться говорить клиенту "Мой софт требует доступа к интернету. Если вы не хотите или не можете обеспечить этого, вот конкуренты (урл, ещё урл), посмотрите, может вам подойдёт", и не испытывать при этом никаких неприятных ощущений.