ASP.NET - Каков наилучший способ заблокировать использование приложения?

Question

Наши клиенты должны платить ежемесячную плату ... если они этого не делают, каков наилучший способ заблокировать использование программного обеспечения asp.net? Примечание. Приложение запускается на собственном клиентском сервере, а не в приложении SaaS ...

Мои идеи:

Идея : размещение в Интернете веб-службы, которую приложение будет использовать, чтобы узнать, может ли клиент использовать программное обеспечение. Выпуск 1 - Что произойдет, если интернет-клиент не работает? Или дата-центр выходит из строя? Возможный ответ : Предоставьте каждой веб-службе доступ к отправке ключа, действительного в течение 7 или 15 дней, поэтому каждая консультация по веб-службе позволит программному обеспечению работать более 7 или 15 дней, таким образом, приложение будет быть заблокированным через 7 или 15 дней без консультации с нашим веб-сервисом. Выпуск 2 - А если клиент не имеет или не хочет включать доступ к приложению через Интернет?

Идея 2 : ежемесячно отправлять ключ клиенту. Выпуск - Как сделать автономный ключ? Возможный ответ : Сгенерировать хэш, используя дату «лимита», чтобы при каждой попытке входа в систему программное обеспечение сравнивало хеш-код сегодняшнего дня с ключом? Выпуск 2 - Где хранить ключ? Возможный ответ : База данных (плохо, слишком легко изменить), текстовый файл, реестр, файл кода, сборка ...

Любое мнение будет очень оценено!

Answer 1

Ах, старая проблема DRM. И это то, о чем вы говорите здесь. Честно говоря, основной ответ на ваш вопрос: вы не можете. Независимо от того, что вы делаете с системой, она может быть взломана и модифицирована таким образом, что ваша схема аутентификации DRM может быть обойдена и / или нарушена.

Это фундаментальный факт разработки программного обеспечения: он может и будет пиратским.

Итак, ответ на ваш вопрос заключается в том, что вам придется доверить клиенту оплатить вам комиссионные, которые вы считаете правильными (в этом и заключается весь смысл договоров).

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

Теперь, если вы хотите управлять своим программным обеспечением в описанном виде, не предоставляйте его пользователям для запуска на их собственных серверах. Заставь их быть SaaS. Таким образом, вы контролируете все это. Но это единственный способ.

Что-то, о чем вы, кажется, не думаете, но я видел сети, которые не допускают каких-либо решений "dial home", так как большинство систем были внутренне ориентированы, и поэтому эти внутренние серверы НЕ были разрешены связаться с внешним интернетом. Совсем. Считалось, что угроза безопасности даже позволила им доступ. Как бы вы справились с этими сетями?

Честно говоря, если бы я был клиентом и заплатил свои сборы за лицензирование вашего программного обеспечения (которое я установил на собственном устройстве), я был бы разгневан, если бы мне пришлось разрешить этому устройству доступ в Интернет, чтобы оно работало , Вдвойне так, если речь шла о каком-либо типе финансового управления, управления клиентами, управления персоналом, управления качеством, управления запасами, продажами или всего, что связано с моим бизнесом, клиентами или сотрудниками. Я недостаточно доверяю разработчикам программного обеспечения, чтобы их программное обеспечение могло говорить с кем-то другим, когда мои бизнес-данные хранятся в их программном обеспечении.

В конце концов, то, что вы описываете, является антагонистическим подходом к вашим платящим клиентам. Если вы мне не верите, посмотрите на комментарии, которые UbiSoft получает для своей последней ненавидящей клиентов схемы DRM.

ИМО, у вас есть два хороших пути:

1. Go SaaS
2. Убедитесь, что ваш контракт имеет укус за неуплату

Answer 2

обычно вы предоставляете шифрованный ключ, который включает в себя действительный токен авторизации и дату истечения срока, до которого услуга оплачивается. Затем установщик будет использовать это для «активации» вашего программного обеспечения. Не уверен, как это будет выглядеть, если у вас есть 1-2 недели. Вы хотели бы предупредить их о предстоящем истечении срока действия. Также не знаете, как узнать, установили ли они свои собственные часы назад.

Короче говоря, ничего не будет идеальным.

Answer 3

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

Однако, если вы настаиваете на использовании чего-то подобного, я предлагаю вам перейти на второй план. Вместо того, чтобы разблокировать приложение только на неделю или две, предоставьте лицензию на 6 месяцев или год. Таким образом, если вы сталкиваетесь с проблемами лицензирования (и вы столкнетесь с проблемами), они возникают только один раз в год, а не пару раз в месяц. Это будет дешевле для вас в поддержке, и ваши клиенты будут менее недовольны решением проблем с лицензированием. Если компания прекращает платить, и вам необходимо аннулировать лицензию, вы можете обработать ее единовременно, применяя при необходимости принудительное выполнение контрактов.

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

Если вы собираетесь хранить лицензию на клиенте, не пытайтесь создать компонент самостоятельно. Есть много доступных компонентов, которые будут намного надежнее и надежнее, чем тот, который вы создаете. Существует .NET .licx-метод лицензирования и ряд сторонних методов , которые вы можете использовать. Какой из них является наиболее подходящим, зависит от вашего сценария: насколько гибко вы хотите получить лицензию и какие другие опции вам нужны. Самое главное, найти что-то надежное - каждый раз, когда ваши клиенты тратят на устранение проблем, связанных с лицензированием, они оказываются непродуктивными и плохо отражаются на приложении.

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

Answer 4

Я согласен со Стивеном, но в конечном итоге я думаю, что ваш контракт - ваш лучший союзник здесь.

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

Что касается SaaS , если бы я был клиентом, использующим ваш продукт, и вы сказали, что модель меняется, и нам нужен доступ к программному обеспечению с вашего сервера и нашегоДолжен быть списан, я не был бы счастлив.Я бы, наверное, воспользовался возможностью для переключения пакетов.

Answer 5

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

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

Что если есть веская причина, по которой они не могут получить доступ к вашему серверу?

• У их интернет-соединения есть проблема.
• У ВАШЕГО интернет-соединения есть проблема.

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

Если вы даете им ежемесячный ключ, вы добавляете ежемесячную досаду, и через некоторое время вы можете потерять клиента (люди, как правило, ведут дела с теми, кто делает это проще).

Например: если вы основываете его на их часах, а приложению нужны точные часы по какой-то причине, маловероятно, что клиент изменит их часы.