|
|
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
Сразу скажу, что мои выводы - в самом конце. Но хотелось бы ваших мыслей и ссылок - где бы почитать по этой теме. Меня интересует больше техническая часть, реализация. Желательно на ASP.NET MVC. Хотелось бы узнать, как строятся веб-приложения и веб-сервисы, работающие по системе подписки. Как контент-провайдеры отслеживают, что подпиской пользуются имеено те люди, которые приобрели её, а не те, которые приобрели, и ещё весь подъезд и все знакомые и родственники приобрётшего? Например, взять подписку MSDN от Майкрософт. Покупаем у вендора подписку, он присылает нам код на почту, на которую зарегистрирован наш аккаут Майкросовта, мы заходим на сайт MSDN и скачиваем то, на что оформлена подписка. При желании можно попросить прислать физические носители с подписанным ПО. При установке подписанного ПО нужно ввести ключ (а можно скачать уже со встроенным ключом - тогда всё ещё проще). Всё. Защит никаких нет. Можно отдать скачанное ПО другу Васе, всему подъезду, всему миру - вместе со своим ключом. Что будет отдавшему ключ - неизвестно. Может, МС с ним больше не будет иметь дела, а может, забьют. В любом случае, на торрентах именно такие - МСДНные - версии всяких продуктов от МС и лежат. МС их в онлайне не банит, после обновления они работать не отказываются. Единственная защита - адресное натравливание юристов , как я понял. Возьмём сервис онлайн-вещания и просмотра кино - например, ivi.ru. При оформлении платной подписки с вас требует только почту и оплатить собственно. Далее, вашего друга, подъезд, весь мир отделяет от просмотра платного контента на ivi.ru только ваш логин и пароль, которые вы можете любезно всем им предоставить. Что может сделать ivi.ru, чтобы оградить весь мир от вашей любезности? Куки? Сертификаты? - Ими тоже можно поделиться. Короче, защиты никакой. Ещё пример - МС Офис 365 - то же, что и с ivi.ru: аккаунт на сайте МС, оплата, привязка через логин-пароль и сертификат. Копируем сертификат, отдаём другу с логином-паролем. Даже если на сайте МС есть проверка одновременной работы с одного айпи - заменяем айпи друга на свой (например, работаем через один прокси, в котором мы можем это сделать). Тут кроме юристов надо ещё и специалистов провайдера привлекать, чтобы доказать факт одновременного использования услуг с одного логина, но с разных айпи. Короче, муторно. Проще забить. И т. д. и т. п. Вот обычное, коробочное ПО как-то шифруют, "железные" токены к нему прикладывают. А с сервисами как быть? Есть мнение, что в погоне за соблюдением правообладательских прав следует не доходить до маразма. Ну, с МС всё понятно - у неё юристы и политика такая - подсадить всех на свои фактически (но не юридически) "индивидуально бесплатные версии", а потом, когда чел пришёл в фирму работать, кроме МС Офиса ничего не знает и умеет эффективно работать только в Visual Studio, то фирма раскошеливается на коробочное ПО или подписку. Мухлёж с пираткой грозит юридическими проблемами. Вот и вся защита. То же и с сервисами потокового вещания - заставь заплатить 10% пользователей, а остальные 90% пусть пользуются и так, раз ума хватило обойти "защиты". Но всё же, что можно сделать для веб-приложений, не относящихся к потоковому вещанию и не имеющих дистрибутивов? Я вот недавно в новостях прочитал, что Твиттер ограничивает доступ к своему айпи по количеству обращений в минуту. Он и раньше это делал, но сейчас ужесточил требования. Есть ли смысл тоже ввести некое число обращений к своему сайта с одного логина, которое будет играть роль "стандартной работы одного пользователя с сайтом"? Скажем, один средний пользователь за месяц наобращается к моим контроллерам (если мы про ASP.NET MVC, к примеру) 10 000 раз. Увеличиваем это дело в 5 раз и после 50 000-го обращения обрубаем юзера? Или не обрубаем, а далее обслуживаем его не чаще, чем клик в минуту. Или в час. Т. е. фактически мы продаём ему 50 000 кликов в месяц, но указываем это только мелким шрифтом в договоре, т. к. законопослушного пользователя это не должно волновать, т. к. все реалистичные сценарии законопослушного использования нашего сайта не выходят и за пятую часть этих кликов. Это примерно та же модель, что у провайдеров - скорость "ДО столько-то мегабит", "пороги" на безлимитных тарифах и прочее. А что, надо же как то выкручиваться? Если провайдерам можно, то почему нам нельзя? Есть ещё модель, когда у пользователя проявляют желание не делиться своими учётными данными - это, например, во всяких онлайн-играх и прочих таких вещах. Там пользователь сам заинтересован, чтобы его учётку не "спёрли". Но там, как правило, это связано с тем, что у пользователя есть некий виртуальный счёт, и он не заинтересован в том, чтобы с этого счёта тратились средства без его ведома. Однако, эта модель снова не работает, когда пользователи пользуются услугой по сгорову и доверяют друг другу. Тогда опять получается, что заплатит один, а пользуются многие. Итого, я вижу пока единственный путь - ввести некоторый ограниченный ресурс, который будет покупаться за деньги и тратиться по мере пользования сервисом (приложением, услугой). В играх это виртуальная валюта и надобность её постоянно тратить, в онлайн-кинотеатре это может быть трафик, отдаваемый на такой-то логин, а в веб-приложении - адекватное одному пользователю число вызовов АПИ. Кто что скажет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 14:15 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
Ну что, ни у кого нет мыслей? Никто не работал над такими проектами? Всё секретно? Дайте хоть направление, куда копать и что читать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 16:48 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
user7320Итого, я вижу пока единственный путь - ввести некоторый ограниченный ресурсМожет путь и не единственный, но вполне подходящий для многих случаев. Для того же онлайн-вещания, например, это может быть единственная онлайн-сессия. Залогинился кто-то другой - тебя вышибло. Например, Steam вторую сессию не пускает. Еще это может быть количество внутренних аккаунтов, физические ресурсы и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 16:54 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
miksoftuser7320Итого, я вижу пока единственный путь - ввести некоторый ограниченный ресурсМожет путь и не единственный, но вполне подходящий для многих случаев. Для того же онлайн-вещания, например, это может быть единственная онлайн-сессия. Залогинился кто-то другой - тебя вышибло. Например, Steam вторую сессию не пускает. Еще это может быть количество внутренних аккаунтов, физические ресурсы и т.п. Стим как определяет, что зашли с другого компа? По заголовкам HTTP - мол, исходный айпи отправителя? Это же ненадёжная информация, которую легко подделать. Но у Стима есть целый клиент, в котором может быть много чего накодено - там можно и ключи свои генерить на каждую сессию. А для веб-приложения так не сделаешь - на клиенте только открытый джаваскрипт может быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 17:12 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
У меня смысл в ресурса в том, что он тратится. Т. е. если пользователь делится своим аккаунтом с другими, то они тратят его ресурс. Т. е. я делаю так, что пользователь становится заинтересован в том, чтобы не давать аккаунт другим. Как банковский счёт. Т. е. смысл в том, чтобы заинтересовать пользователя не делиться своим аккаунтом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 17:14 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
авторСкажем, один средний пользователь за месяц наобращается к моим контроллерам (если мы про ASP.NET MVC, к примеру) 10 000 раз. Увеличиваем это дело в 5 раз и после 50 000-го обращения обрубаем юзера? Или не обрубаем, а далее обслуживаем его не чаще, чем клик в минуту. Или в час. Т. е. фактически мы продаём ему 50 000 кликов в месяц, но указываем это только мелким шрифтом в договоре, т. к. законопослушного пользователя это не должно волновать, т. к. все реалистичные сценарии законопослушного использования нашего сайта не выходят и за пятую часть этих кликов. Это примерно та же модель, что у провайдеров - скорость "ДО столько-то мегабит", "пороги" на безлимитных тарифах и прочее. А что, надо же как то выкручиваться? Если провайдерам можно, то почему нам нельзя? Ещё примерно такая же модель у держателей игровых консолей. Вы можете "поделиться" игрой с одним-тремя (в разное время разные числа озвучивались) пользователями официально. Т. е. держатели платформ закладывают, что купив игру один раз, она попадёт в двео-четверо рук. Вот и я тоже - пусть заплатит только каждый четвёртый-пятый (максимально закладываемая недополученная прибыль), но хотя бы эти 20% должны заплатить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 17:20 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
С одной стороны, у тебя за кадром есть вполне определённый, и, видимо, уже вышедший на уровень промышленной эксплуатации, сервис, своего типа, со своими особенностями. С другой стороны, ты пытаешься обсуждать вопрос "вообще". Но вещи-то между собой не сильно равные, и при такой широкой постановке вопроса не будет ничего, кроме бессмысленного трясения воздуха. Может, разумнее обсуждать не вопрос вообще, а тебе - описать по максимуму имеющийся и предназначенный к защите сервис, нам - высказывать мысли по защите в совершенно конкретной ситуации. Ну а уже в качестве ненаказуемого полуоффтопа можно будет потрындеть о технологиях такой защиты вообще. Имхо пользы больше будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 17:24 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
user7320miksoftпропущено... Может путь и не единственный, но вполне подходящий для многих случаев. Для того же онлайн-вещания, например, это может быть единственная онлайн-сессия. Залогинился кто-то другой - тебя вышибло. Например, Steam вторую сессию не пускает. Еще это может быть количество внутренних аккаунтов, физические ресурсы и т.п. Стим как определяет, что зашли с другого компа? По заголовкам HTTP - мол, исходный айпи отправителя? Это же ненадёжная информация, которую легко подделать. Но у Стима есть целый клиент, в котором может быть много чего накодено - там можно и ключи свои генерить на каждую сессию. А для веб-приложения так не сделаешь - на клиенте только открытый джаваскрипт может быть.Да почему же не сделаешь? TCP-соединения разные - все, в лес. Да и обычная сессия в браузере - тоже вполне себе различается одна от другой (хотя в одной сессии может быть и несколько TCP-соединений). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 17:25 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
user7320У меня смысл в ресурса в том, что он тратится. Т. е. если пользователь делится своим аккаунтом с другими, то они тратят его ресурс. Т. е. я делаю так, что пользователь становится заинтересован в том, чтобы не давать аккаунт другим. Как банковский счёт. Т. е. смысл в том, чтобы заинтересовать пользователя не делиться своим аккаунтом. Правильно понимаю что чем больше ресурса тратится юзером тем больше ты зарабатываешь? Если так, то пусть юзер раздает свой аккаунт и платит за себя и всех кому раздал. В чем проблема? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 17:26 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
Dima Tuser7320У меня смысл в ресурса в том, что он тратится. Т. е. если пользователь делится своим аккаунтом с другими, то они тратят его ресурс. Т. е. я делаю так, что пользователь становится заинтересован в том, чтобы не давать аккаунт другим. Как банковский счёт. Т. е. смысл в том, чтобы заинтересовать пользователя не делиться своим аккаунтом. Правильно понимаю что чем больше ресурса тратится юзером тем больше ты зарабатываешь? Если так, то пусть юзер раздает свой аккаунт и платит за себя и всех кому раздал. В чем проблема? Что-то типа того. Только штука в том, что юзер, узнав, что раздав свой аккаунт, он лишится доступа к сервису не через месяц, а через неделю, может "обидиться" и не захотеть продлевать подписку. Проблема здесь в том, что сказать юзеру, что подписка фактически не на месяц, а на 50 000 обращений к АПИ, тоже вроде как нельзя. Во-первых, это в диковинку для юзеров - что за такие подписки на "обращения"? Юзер не специалист и в этом не разбирается. А во-вторых - юзеру придётся выставить какой-то адекватный счётчик, постоянно заставлять его контролировать этот счётчик. А с подпиской на время проще - юзер знает, что всё закончится "в конце этого месяца", например. AkinaС одной стороны, у тебя за кадром есть вполне определённый, и, видимо, уже вышедший на уровень промышленной эксплуатации, сервис, своего типа, со своими особенностями. С другой стороны, ты пытаешься обсуждать вопрос "вообще". Но вещи-то между собой не сильно равные, и при такой широкой постановке вопроса не будет ничего, кроме бессмысленного трясения воздуха. Может, разумнее обсуждать не вопрос вообще, а тебе - описать по максимуму имеющийся и предназначенный к защите сервис, нам - высказывать мысли по защите в совершенно конкретной ситуации. Ну а уже в качестве ненаказуемого полуоффтопа можно будет потрындеть о технологиях такой защиты вообще. Имхо пользы больше будет. Сервиса ещё как такового нет, только разрабатывается. Но интересно знать, как подобные сервисы защищаются. Ну и монетизируются. miksoftuser7320пропущено... Стим как определяет, что зашли с другого компа? По заголовкам HTTP - мол, исходный айпи отправителя? Это же ненадёжная информация, которую легко подделать. Но у Стима есть целый клиент, в котором может быть много чего накодено - там можно и ключи свои генерить на каждую сессию. А для веб-приложения так не сделаешь - на клиенте только открытый джаваскрипт может быть.Да почему же не сделаешь? TCP-соединения разные - все, в лес. Да и обычная сессия в браузере - тоже вполне себе различается одна от другой (хотя в одной сессии может быть и несколько TCP-соединений). А если я по HTTP работаю? Как вы различаете одну сессию от другой? Допустим, юзер скопировал куки с одной машины на другую и пользуется сервисом с той же сессией, что "осталась" на прежней машине. При этом и на прежней та же сессия запущена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 19:42 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
user7320Возьмём сервис онлайн-вещания и просмотра кино - например, ivi.ru. При оформлении платной подписки с вас требует только почту и оплатить собственно. Далее, вашего друга, подъезд, весь мир отделяет от просмотра платного контента на ivi.ru только ваш логин и пароль, которые вы можете любезно всем им предоставить. Что может сделать ivi.ru, чтобы оградить весь мир от вашей любезности? Куки? Сертификаты? - Ими тоже можно поделиться. Короче, защиты никакой. Он может показывать кино только одному пользователю, зарегистрированному на их сайте. Другим сессиям этого же пользователя кино уже НЕ показывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 19:51 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
user7320А если я по HTTP работаю?Не поверите, но HTTP тоже работает поверх TCP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 19:54 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
miksoftuser7320Итого, я вижу пока единственный путь - ввести некоторый ограниченный ресурсМожет путь и не единственный, но вполне подходящий для многих случаев. Для того же онлайн-вещания, например, это может быть единственная онлайн-сессия. Залогинился кто-то другой - тебя вышибло. Например, Steam вторую сессию не пускает. Еще это может быть количество внутренних аккаунтов, физические ресурсы и т.п. Ну кстати в случае кинотеатров таким ресурсом может быть суммарное время просмотра в месяц. Например, если человек постоянно смотрит кино, то это -- 31*24 = 744 часа в месяц. Если он смотрит параллельно в 2 глаза на двух устройствах -- это уже будет в два раза больше, так что если это ограничить, то очень многим пользователям свою учётку он не раздаст -- просто все быстро выберут лимит по времени и всё выключится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 19:57 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
user7320Допустим, юзер скопировал куки с одной машины на другую и пользуется сервисом с той же сессией, что "осталась" на прежней машине.На простых сайтах, действительно, сессия может быть угнана таким образом. Однако, более продвинутые сайты при этом проверяют, чтобы все соединения одной сессии были с одного и того же ip-адреса, что в случае разных машин возможно, только если они "сидят" за общим NAT-ом. Еще более продвинутые сайты регулярно меняют идентификатор сессии, т.е. уже через несколько секунд старые куки будут бесполезны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 20:10 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
ну да прикольно, т.е. я заплатил свои кровные за сервис и после этого буду всем давать свой акаунт? я что мать тереза? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 20:49 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
user7320Dima Tпропущено... Правильно понимаю что чем больше ресурса тратится юзером тем больше ты зарабатываешь? Если так, то пусть юзер раздает свой аккаунт и платит за себя и всех кому раздал. В чем проблема? Что-то типа того. Только штука в том, что юзер, узнав, что раздав свой аккаунт, он лишится доступа к сервису не через месяц, а через неделю, может "обидиться" и не захотеть продлевать подписку. Проблема здесь в том, что сказать юзеру, что подписка фактически не на месяц, а на 50 000 обращений к АПИ, тоже вроде как нельзя. Во-первых, это в диковинку для юзеров - что за такие подписки на "обращения"? Юзер не специалист и в этом не разбирается. А во-вторых - юзеру придётся выставить какой-то адекватный счётчик, постоянно заставлять его контролировать этот счётчик. А с подпиской на время проще - юзер знает, что всё закончится "в конце этого месяца", например. Всё должно быть прозрачно. Как с электросчетчиком. Тогда юзеру будет понятно: потратил 100 кВт - заплатил 100 р, потратил 200 - заплатил 200. Напрягает не дороговизна, а непонятность начисления. Если твой сервис будет давать понятные и очевидные начисления то большинство не спросит почему так. И не надо пытаться придумать как твоему потребителю съэкономить, если ему это не надо, то тебе это зачем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2014, 21:17 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
mvn3ну да прикольно, т.е. я заплатил свои кровные за сервис и после этого буду всем давать свой акаунт? я что мать тереза? Можно простой пример - купили лиценцию на один комп (сервер предприятия), а пользуются всей подсетью предприятия. В результате мой сервер дымит и я оплачиваю бешеные счета за электричество, а эти умники и в ус не дуют и платят мне копейки. Если сразу задрать цену - отпугнёт клиентов, которым действительно только им одним этот сервис и нужен. Если проводить гибкую политику и предлагать разные цены для разных заказчиков, то что заставит крупные конторы с кучей пользователей покупать не самую дешёвую лицензию, а лицензию на всех своих пользователей? Сейчас так и делают - организация покупает одну лицензию и кучу пиратки. Приходят проверяльщики - они им лицензию. Если проверяльщики смотрят ещё и компы пользователей, а не просто удовлетворяются показанной лицензией, то происходит более глубокая подготовка. Но обычно проверяльщики предупреждают заранее, так что время есть... Короче, когда кого-то наказывают из крупных контор за пиратское ПО - это скорее говорит о том, что кто-то "на кого-то наехал", "не занёс", "не поделился", "а *ули тут так мало?!" и т. п. "бред обрыдшей реальности". Преследование адвокатами фирмы-правообладателя - экзотический случай. Короче, хочешь защитить своё ПО - должен сам об этом позаботиться, а не на законы опираться. Это в нашей стране, по крайней мере. И я предложил способ, который, как я думаю, будет рабоатать в таких реалиях - заставить пользователя самого быть заинтересованным в сохранении своего аккаунта только у себя. Т. е. нужно ввести тратящийся ресурс. miksoftuser7320Допустим, юзер скопировал куки с одной машины на другую и пользуется сервисом с той же сессией, что "осталась" на прежней машине.На простых сайтах, действительно, сессия может быть угнана таким образом. Однако, более продвинутые сайты при этом проверяют, чтобы все соединения одной сессии были с одного и того же ip-адреса, что в случае разных машин возможно, только если они "сидят" за общим NAT-ом. Еще более продвинутые сайты регулярно меняют идентификатор сессии, т.е. уже через несколько секунд старые куки будут бесполезны. Общий NAT - вполне себе способ неправомерного использования моего сервиса. Насчёт идентификатора сессии - посмотрю. Кстати, всё это, как я понимаю - пока даже без применения сертификатов, SSL и прочих шифрующих штучек, да? Ведь по сути, с сертификатами можно как и с куками - просто скопировать на другую машину. Dima Tuser7320пропущено... Что-то типа того. Только штука в том, что юзер, узнав, что раздав свой аккаунт, он лишится доступа к сервису не через месяц, а через неделю, может "обидиться" и не захотеть продлевать подписку. Проблема здесь в том, что сказать юзеру, что подписка фактически не на месяц, а на 50 000 обращений к АПИ, тоже вроде как нельзя. Во-первых, это в диковинку для юзеров - что за такие подписки на "обращения"? Юзер не специалист и в этом не разбирается. А во-вторых - юзеру придётся выставить какой-то адекватный счётчик, постоянно заставлять его контролировать этот счётчик. А с подпиской на время проще - юзер знает, что всё закончится "в конце этого месяца", например. Всё должно быть прозрачно. Как с электросчетчиком. Тогда юзеру будет понятно: потратил 100 кВт - заплатил 100 р, потратил 200 - заплатил 200. Напрягает не дороговизна, а непонятность начисления. Если твой сервис будет давать понятные и очевидные начисления то большинство не спросит почему так. И не надо пытаться придумать как твоему потребителю съэкономить, если ему это не надо, то тебе это зачем? Согласен. Но в этом-то и проблема - что это может быть за такой тратящийся ресурс, но при этом понятный и прозрачный для пользователя? И именно в применении к веб-приложениям, а не для видеосервисов или онлайн-игр с виртуальной валютой. Брать плату (даже пусть самую мизерную) за каждый клик по ссылке на моём сайте? - Не поймут. Лимит обращений к АПИ? - Простые юзеры не поймут. Это для программистов ещё понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2014, 07:22 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
user7320Но в этом-то и проблема - что это может быть за такой тратящийся ресурс, но при этом понятный и прозрачный для пользователя? И именно в применении к веб-приложениям, а не для видеосервисов или онлайн-игр с виртуальной валютой.Посмотрите как сделано на конкурирующих сайтах. Например, можно ограничивать количество внутренних аккаунтов внутри одного аккаунта более высокого уровня. Или объем хранимых данных. Можно придумывать еще долго, но без подробностей это просто тыкать пальцем в небо, как правильно заметил выше Akina. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2014, 09:32 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
user7320Если проводить гибкую политику и предлагать разные цены для разных заказчиков, то что заставит крупные конторы с кучей пользователей покупать не самую дешёвую лицензию, а лицензию на всех своих пользователей? Сейчас так и делают - организация покупает одну лицензию и кучу пиратки. Приходят проверяльщики - они им лицензию. Если проверяльщики смотрят ещё и компы пользователей, а не просто удовлетворяются показанной лицензией, то происходит более глубокая подготовка. Но обычно проверяльщики предупреждают заранее, так что время есть... Ты тут рассуждаешь как борцы с пиратами. Если купили 1 лицензию, а поставили 100 копий, то можно было бы заработать в 100 раз больше. Не факт что все 100 используются и можно безболезненно снизить до 50-30, просто админ понаставил на всякий случай. user7320Кстати, всё это, как я понимаю - пока даже без применения сертификатов, SSL и прочих шифрующих штучек, да? Ведь по сути, с сертификатами можно как и с куками - просто скопировать на другую машину. Ты только не перестарайся с безопасностью, а то пользователь решит что ему нафиг не надо шаманства с настройками и найдет другой подобный сервис. user7320Но в этом-то и проблема - что это может быть за такой тратящийся ресурс, но при этом понятный и прозрачный для пользователя? И именно в применении к веб-приложениям, а не для видеосервисов или онлайн-игр с виртуальной валютой. Тут от сервиса зависит. От задачи которую он решает. Для чего-то ведь пользователь его использует, явно не для того чтобы тратить электричество на твоем сервере. Цена зависит от той услуги которую получает твой пользователь. По-хорошему цена должна быть пропорциональна объему полученного пользователем. user7320Брать плату (даже пусть самую мизерную) за каждый клик по ссылке на моём сайте? - Не поймут. Лимит обращений к АПИ? - Простые юзеры не поймут. Это для программистов ещё понятно. Так точно делать не стоит, получишь мульон рацпредложений как улучшить сайт/апи для минимизации количества кликов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2014, 09:39 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
miksoftМожно придумывать еще долго, но без подробностей это просто тыкать пальцем в небо, как правильно заметил выше Akina.+1 Сделать аутентификацию при помощи Facebook и ВКонтакте и фиг пользователи будут делиться своими аккаунтами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2014, 10:28 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
skyANAmiksoftМожно придумывать еще долго, но без подробностей это просто тыкать пальцем в небо, как правильно заметил выше Akina.+1 Сделать аутентификацию при помощи Facebook и ВКонтакте и фиг пользователи будут делиться своими аккаунтами Ничего это не даёт. Просто к цене подписки на одного пользователя добавляется цена симки в 100 рублей. И дальше всё также: регают акк в Фейсбуке, регаются у меня, юзают мой сервис всем миром. Фейсбуки с Вконтактами помогут разве что от ботов, регающих на сайте учётки. Но и то это в дополнение к капче. Dima Tuser7320Брать плату (даже пусть самую мизерную) за каждый клик по ссылке на моём сайте? - Не поймут. Лимит обращений к АПИ? - Простые юзеры не поймут. Это для программистов ещё понятно. Так точно делать не стоит, получишь мульон рацпредложений как улучшить сайт/апи для минимизации количества кликов. Рацпредложения были всегда и от них не избавиться. В онлайн-играх это гайды по "оптимальной раскачке" и услуги "провода по подземельям" и т. п.. В продажах на консолях это покупки вскладчину дисков или учёток без привязки к железу. Не считаю наличие рацпредложений для преодоления препятствия минусом препятствия. Действительный минус, как я сказал - непонятность и незнакомость клиенту. Dima Tuser7320Кстати, всё это, как я понимаю - пока даже без применения сертификатов, SSL и прочих шифрующих штучек, да? Ведь по сути, с сертификатами можно как и с куками - просто скопировать на другую машину. Ты только не перестарайся с безопасностью, а то пользователь решит что ему нафиг не надо шаманства с настройками и найдет другой подобный сервис. Я имел ввиду сертификаты, с которыми браузеры работают, а не те, которые надо руками или через программы установки во всякие хранилища сертификатов устанавливать на той же Винде. Вроде, HTTPS ещё никого не напрягал и юзеры даже не подозревают, где происходит переход с HTTP на HTTPS, если не обращаются внимания на адресную строку. А в последнее время браузеры стали по умолчанию скрывать протокол от юзеров в адресной строке - вообще хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2014, 11:59 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
miksoftuser7320Но в этом-то и проблема - что это может быть за такой тратящийся ресурс, но при этом понятный и прозрачный для пользователя? И именно в применении к веб-приложениям, а не для видеосервисов или онлайн-игр с виртуальной валютой.Посмотрите как сделано на конкурирующих сайтах. Например, можно ограничивать количество внутренних аккаунтов внутри одного аккаунта более высокого уровня. Или объем хранимых данных. Можно придумывать еще долго, но без подробностей это просто тыкать пальцем в небо, как правильно заметил выше Akina. Так я и приводил в пример другие сайты - онлайн-игры, онлайн-кинотеатры, Офис 365 и подобные продукты. Под моё подходит только Офис 365 в виде HTML-приложения, запускаемого в браузере, т. к. у меня именно такое приложение - веб-приложение, запускаемое в браузере, по сути, сайт: ссылка (там надо нажать попробовать, имея аккаунт LiveID). Но про МС вообще я уже расписал. А как в части безопасности и отслеживания пользователей работает Офис 365 я не знаю и инфу не найти. Может, кто знает и расскажет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2014, 12:06 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
Ещё такую штуку придумал - ограничение на число запросов в единицу времени. Скажем, не более 1 запроса в 2 секунды. Чтобы не было маразма - ограничивать так запросы только к функциональным элементам. Скажем, на вызов АПИ, а не на загрузку картинок оформления сайта. Тогда пусть попробуют толпой поработать с одной аккаунта - замучаются ждать ответа от сервера. Что тут хорошо, что такие ограничения относятся к разряду ограничений за запросы вообще. Т. е. возможно, что у вас уже готова такая функциональность по ограничения запросов в единицу времени. Теперь остаётся только для определённых действий поднастроить эту функциональность. В ASP.NET MVC это может быть просто изменение параметра конструктора в атрибуте контроллера, а сами атрибуты уже реализованы в коде и расставлены по контроллерам и методам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2014, 13:00 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
авторЕщё такую штуку придумал - ограничение на число запросов в единицу времени. Скажем, не более 1 запроса в 2 секунды. Это для одного аккаунта, а не вообще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2014, 13:01 |
|
||
|
Способы защиты веб-приложений и сервисов с подпиской
|
|||
|---|---|---|---|
|
#18+
Вы не с теми сайтами сравниваете. Сравните, например, сайты по законодательству (ЛигаЗакон) или рассылка смс (ТурбоСМС). Чтобы начать пользоваться - авторизуйся. Потом пользуйся согласно расценок. Клиент за живые деньги покупает виртуальные "деньги", типа "юниты", и тратит их. Хочеш скачать "закон" - уплати 2 юнита. Хочеш отправить СМС - плати N-юнитов. Зашел в свой аккаунт, посмотрел расходы (за что когда платил). Что тут не понятного, нового, сложного? Это реально работает. На лицо "мотивация" клиента управлять своими расходами и беспокоится за их сохранность. И последнее. Клиент купил "юниты" и в праве их использовать как хочется ему, т.е. и поделится с другом. Если пользуются на пару по согласию, то на этой паре даже теоритически больше не заработать, т.е. Вы ничего не теряете. А не материальный доход - это скрытая реклама, которую клиент дает своему другу. И наступет день и этот друг сам себе купит эти самые юниты. Теория о будущих доходах ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2014, 15:48 |
|
||
|
|

start [/forum/topic.php?fid=16&tid=1341438]: |
0ms |
get settings: |
6ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
154ms |
get topic data: |
8ms |
get forum data: |
1ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 215ms |
| total: | 452ms |

| 0 / 0 |
