Извиняюсь за повтор темы. Но в теме "Программирование" что-то не отвечают. Может, потому, что я не ASP.NET'чиков спросил. Тут, наверное, лучше будет.

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

http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1075109&msg=15725902

st_stЯ клиенту внедрил сниффер и получил полный запрос и ответ (заголовки + данные), то есть куки, user-agent и прочее. У себя на компьютере делаю идентичный запрос на сервер. Сервер естественно меня принимает за своего. Меняю пароли, списываю бабосы со счетов, в общем делаю всё что хочу. Каким образом та система защитит от этого? Запросы идентичны - и куки и браузер (юзер-агент) и ОС и т.д.

Единственное, что не подменишь - это ip-адрес (слепой спуффинг оставим на теоретических началах), отсюда - единственное, к чему можно привязаться - это ip.

Второе - все важные действия, такие как смена пароля, оплата и прочее имеют как минимум две ступени защиты, то есть например без получения кода на телефон (СМС), пользователь не может ничего оплатить или совершить какие-нибудь серьёзные действия и тогда кража кук не приведёт к краху аккаунта.
Вот, это уже лучше! Хотя бы обсуждение началось. А то все молчат...

Сниффер - это понятно. Так можно сказать, что внедрил клиенту паяльник... дальше не буду.

Про подтверждение всяких важных действий по СМС и т. п. - это тоже понятно. Это я согласен.

Про айпи - это тоже всё сменяемо. Я начитался по способам создания "слепков" с браузера и системы пользователя - всё это фигня. Просто потому, что можно иметь свой прокси и подменять что угодно на что угодно.

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

Обычный клиент бы просто раз залогинился в новом браузере и всё. Если перешёл на другой браузер - на старом снова приходится залогиниваться. Если не переходит - работает на старом и дальше. Вот и всё.

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

Т. е. это не система защиты данных клиента от снифферов или ещё чего. Это система защиты нас от недобросовестных клиентов ("пиратов", так сказать). Клиенты будут защищаться... ну, пока шифрованных каналом (обычный SSL) и тем, что вы сказали - подтверждение важных действий альтернативными методами.

st_stЯ на работе с утра до вечера на одном браузере, дома вечером на другом, на телефоне иногда в течении дня - на третем. Если меня будет постоянно разлогинивать, то я возненавижу данный сайт. Это больше не защита, а раздражение пользователя.

Про подмену ip приведу пример - пользователь подключен к провайдеру, ему выдан ip 188.150.210.120 (взял наугад). Попробуйте с этого ip добавить сообщение на форуме, не врезаясь в подъезде в сетевой кабель клиента. Можете использовать свои прокси или как их там.

> На самом деле, задача моей защиты - недопустить, чтобы под одной учёткой работало более одного пользователя.

Зачем ставить непонятные запреты пользователю от мифических пиратов?
Согласен про неудобства. Я буду думать над этим. Возможный вариант решения в спойлере ниже.



Про айпи это не выход. У некоторых провайдеров динамические айпи, меняющиеся после переподключения пользователя. Плюс пользователи могут сидеть за прокси (корпоративный, местной локалки подъезда, сотового оператора - да какого угодно). Вобщем, привязка к айпи это как привязка к одному рабочему месту - ещё хуже, чем моя затея с постоянными перелогиниваниями. Я тут не вижу пока решения с айпи.

Про пиратов. Это я не пользователя от пиратов защищаю, а нас от пользователей-пиратов. Купил, допустим, пользователь у нас одну копию, получил одну учётку. А раздал всем сотрудникам на предприятии. И ладно, если это 3-5 человек. А если 30-50? Мы на одной поддержке оборудования для работы с такой толпой (а они же не единственные клиенты у нас будут) не окупимся.

st_stПривязка к ip это защита пользователя при краже кук. У вас же как я понял из последнего сообщения - защить себя (чтобы юзеры не продавали свои аккаунты), а не пользователя. Посмотрите в сторону usb-токенов .
Мы от подобных токенов наоборот, отказаться хотим.

st_stА мы один раз только залогинимся. Главный юзер авторизуется, получает куку, тут же программно автоматом копирует эту куку по всем браузерам предприятия и работаем в количестве 50 человек под одним аккаунтом. Сессию (если она есть) просто продлеваем редкими автоматическими запросами. Смысл в другом - городить это у себя на предприятии никто не станет, хотя вариант и возможен.
Я это и имел ввиду под синхронизацией куки между браузерами пользователей. Такая штука, естественно, сломает мою защиту. Только я тоже на то и рассчитывал, что городить это у себя никто не станет.

Antonariyuser7320На самом деле, задача моей защиты - недопустить, чтобы под одной учёткой работало более одного пользователя. Всё. И зачем для этого такой огород? Решение элементарное и ископаемое: при повторной авторизации закрывать первую сессию. Второй юзер заходит, первый вылетает. Всё.
Как я распознаю, где первый, а где второй? По айди сессии? Так это всё в куки хранится - легко скопировать или подделать. Причём достаточно скопировать один раз. А при постоянной смене куки их надо копировать постоянно.

Кроме того, как мне закрыть сессию предыдущего пользователя, когда ко мне послал запрос следующий? Если что, я использую FormsAuthentication.

Antonariyтакие проблемы нужно решать юридически, а не технически. собрать факты нарушения лицензионного соглашения и пригрозить судом.
Юридически - это понятно. Осталось только собрать факты ))) А в это время часики-то тикают и расходы-то идут. И при этом всё должно выглядеть цивильно, а не скандал с обрубанием сервиса пользователю. Лучше заранее предупредить, что частая смена браузера приведёт к перелогиниваю, и в лиц. соглашение это.

Ещё раз пишу, что можно несколько раз подряд идущих несовпадений куки пропускать - пусть это будет поправка на смену пользователем браузера в течении рабочего дня. Раз 10 пропустить. Теперь добавим сюда (это я щас придумал), что число подряд идущих несовпадений будет обнуляться, скажем, каждый час. В результате получим, что нормальный пользователь может даже не заметить работы системы и система не будет его спрашивать перелогиниться вообще никогда. А вот когда хотя бы двое начинают работать под одним акком одновременно, то лимит несовпадений быстро исчерпается и пойдут запросы на перелогинивание. Каково, а?

авторЕсли что, я использую FormsAuthentication.
Но это только для залогинивания на сайте и создания сессии на сайте. А для защиты и использую самописный ActionFilter, который усиленно юзает Profile.

user7320авторЕсли что, я использую FormsAuthentication.
Но это только для залогинивания на сайте и создания сессии на сайте. А для защиты и использую самописный ActionFilter, который усиленно юзает Profile.
Потому что такая защита должна работать только на определённых контроллерах и действиях, а не на всём сайте целиком.

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

Но и тут есть минус - перед кем доказывать? Подряд идущие совпадения куки явно не являются юридически доказательством. Моя схема - не признанная экспертами и наверняка имеет изъяны. Это для внутреннего пользования.

Antonariyuser7320А в это время часики-то тикают и расходы-то идут.А расходы оплачивает клиент через суд, если не удалось его образумить.
Когда дело дойдёт до суда - согласен. Только опять же, суд - это непредпочтительный вариант. Предпочтительный - чтобы всё происходило тихо-мирно. Желательно, в автоматическом режиме.

st_stЛимит вызовов назовём это API-методами сервера в сутки из-под одного клиентского аккаунта не вариант? При превышении лимита - либо платно вызовы сверх нормы, либо письмо клиента с объяснением зачем ему нужно больше.
В принципе, вариант. Тоже можно через фильтр и поставить эти фильтры только на те методы, которые критичны. Чтобы всякие подгрузки картинок интерфейса не считались за вызовы АПИ. Вроде, схема простейшая - увеличивай счётчик при каждом ображении и всё. Гораздо проще, чем у меня.

Но тут тоже есть минус - придётся анализировать работу всех действий контроллеров всего сайта. Может, там при одних сценариях работы вызовы интенсивно используются, а при других - за час только 20 раз... Хотя, можно просто взять с запасом в разы.

Я это и раньше обсуждал (в той теме по ссылке в первом сообщении этой темы). Минус - трудно презентовать такую монетизацию заказчикам. "Количество вызовов АПИ" - не очень понятная схема для простых людей. Это не техспециалисты - мы им не АПИ продаём. Это готовые веб-приложения. Это что, на кнопочки много жать не надо? Начнут придумывать стратегии экономичного пожатия кнопочек... Вобщем, выглядит как-то глупо перед простыми клиентами, хотя для техспециалиста вполне себе нормально.

Я оставлю это на запасной вариант.

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

Неужели я первый?



Однако, непонятно, как работает тот же Офис 365 у Майкрософт. Который на ХТМЛе сделан и через браузер работает. Неужели один логин-пароль и никакой привязки к браузеру, железу и т. п.? Фактически, бесплатная рекламная версия (купил раз и раздал всем) для заманивания на десктопный вариант.

Antonariyuser7320 Судя по неуверенным комментариям (что здесь, что в теме по ссылке в первом посте), народ либо такого никогда не делалТы как-то мудрено там все расписал, но если суть в том, чтобы менять куку при каждом запросе, то я так собирался сделать, но не стал, потому что это не будет работать при использовании ajax.

Допустим, ты сделал один ajax-запрос с валидной кукой, и, не дожидаясь ответа, второй запрос. Первый запрос на сервере отработал, поменял куку, и тут приходит второй запрос, а кука-то у него старая — запрос обломался.
А если ввести счётчик невалидных куки и "прощать" пользователю некое число, которое можно объяснить аджаксами, задержками и прочими непредвиденными обстоятельствами? Скажем, 10. Тогда один пользователь сможет нормально работать и с аджаксами, а двое сразу быстро выберут лимит десятки. Ну и счётчик обнулять периодически. В конкретной реализации можно поиграть значениями (сколько прощать, через сколько обнулять).

Ну и, естественно, дизайн приложения делать такой, чтобы самому себе не отправлять подряд по 10 аджаксов.

А?

AntonariyПри твоей же схеме, даже если ты нашел защиту от пиратов, возможен вариант, когда запускается скрипт, юзающий единственный легальный логин и производящий нагрузку как дюжина пользователей. Часики тикают, расходы идут, а предъявить клиенту нечего — все в рамках соглашения.
Это уже на сервере надо ограничивать число запросов в секунду. Вроде, это и в IIS встроенное есть. И не только в IIS. И это вообще относится ко всем сайтам, а не только к защите подписочных сервисов - так можно любой сайт за'DDOS'ить.

AntonariyЕдинственный беспроигрышный вариант — продавать не логины, а ровно то, по чему у тебя "тикают часики" и идут расходы, — нагрузку. То есть некую величину, вычисляемую из количества запросов в период времени и, возможно, траффика. Как киловатт-часы. И влепить на страничку нагружометр по аналогии с крутящимся диском счетчика. Тогда количество логинов не имеет значения. При этой схеме пользователю все понятно и финансово прозрачно, а мимо тебя не проскочит и копейка. Однако под это дело нужна толковая математическая модель, которую лично я пока не представляю.
Кроме вами названного, тут минус ещё и тот же, что я раньше описывал - такая схема монетизации для простого пользователя слишком новая и непонятная. Людям не нравится, когда их на счётчик посекундный ставят (счётчик же будет обновляться буквально после каждого запроса). Это жутко нервирует. Как интернет с повременной оплатой.

user7320А если ввести счётчик невалидных куки и "прощать" пользователю некое число, которое можно объяснить аджаксами, задержками и прочими непредвиденными обстоятельствами? Скажем, 10. Тогда один пользователь сможет нормально работать и с аджаксами, а двое сразу быстро выберут лимит десятки. Ну и счётчик обнулять периодически. В конкретной реализации можно поиграть значениями (сколько прощать, через сколько обнулять).

Ну и, естественно, дизайн приложения делать такой, чтобы самому себе не отправлять подряд по 10 аджаксов.

А?
Тут ещё штука, что я не абсолютную защиту горожу. Скажем, двое, наверное, смогут работать и одновременно. Но вот уже 10 - навряд ли. А мне это и надо - чтобы толпу за один аккаунт не посодили. Мы не жадные, если что - и троих одновременно обслужим. Просто эти "потери" заранее будут закладываться в цену подписки. "Потери из-за неплатежей по кредитам включены в конечную стоимость кредита. За неплатящих платят платящие". Пользователям, конечно, мы об этом не скажем.

А?

Antonariyuser7320А если ввести счётчик невалидных куки и "прощать" пользователю некое число, которое можно объяснить аджаксами, задержками и прочими непредвиденными обстоятельствами?Мало формализма, много эмпирики, плохо. Периодически будут случаться неочевидные вылеты сессии и прочие плохо прогнозируемые спецэффекты.

Если это single-page приложение, то единственный выход это сделать куку не одноразовую, а короткоживущую и обновляемую специальным запросом по таймеру, а на время обновления (которое будет приемлемо мизерным) ставить прочие ajax-запросы в очередь.
Приложение не сингл-пейдж.

Кука не одноразрвая, а обновляемая. Но не по таймеру. Я храню на сервере и в этой куке время устаревания этой куки. Время устаревания обновляется при запрсе пользователя, если кука устарела. Обновление происходит на случайную величину в промежутке от нескольких секунд до 20 секунд. Естественно, все конкретные числа можно настраивать через web.config.

Насчёт аджаксов. Есть страница, которая обновляет своё основное содержимое (большой раздел в теле HTML-документа) одним аджаксом. Это на что-то влияет? Разве аджакс-запрос не такой же, как и обычный? Аджаксы же тоже отсылают куки и прочее, присущее обычным запросам? Т. е. я тут вообще не усматриваю разницы работы через обычные запросы или асинхронные при моей реализации работы с куки (см. абзац выше).


Насчёт остального - вы предлагаете, как я понял, ограничение вызовов действий контроллеров (или АПИ) в единицу времени. Скажем, не более 120 в минуту или примерно так? Я пока рассматриваю это как следующую альтернативу своему методу. Дело в том, что тут тоже есть своя сложность. Например, если поставить ограничение 30 в минуту или меньше, то это может быть распознано как "тормозящий сайт". А если 120 или больше - как "да мы можем и подождать", и будут 20 человек обновлять свои странички не 30 раз в минуту, а 3 раза - для многих это будет вполне достаточно для многих видов работы с моим сайтом - загрузил информацию и воспринимай. В моём же варианте подсчёта несовпадающих куки я хотя бы раз в несколько минут заставляю эту кучу пользователей перелогиниваться вне зависимости (в разумных пределах, конечно) от того, сколько они будут выжидать после очередного запроса на мой сайт. Просто, чем дольше они будут ждать - т. е. чем меньше делать запросы на сайт - тем позже им придётся перелогиниться. Но всё равно придётся, т. к. лимит прощённых несовпадающих куки всё равно довольно быстро исчерпывается, а обнуляться этот счётчик будет не так уж часто (скажем, раз в час).

Кстати, про лимит прощённых несовпадающих куки. Это можно тоже рассматривать как тратящийся ресурс, как и обращения к сайту.

Вобщем, я плюсы вашего метода вижу такие:
- проще реализовать - буквально счётчик типа counter++ с минимальной обвязкой;
- подмена куки, включая все монструозные автоматизированные решения по синхронизации куки между всеми браузерами, работающими под одним аккаунтом на моём сайте, не будет работать - это существенный плюс.

А минусы такие:
- трудно преподнести пользователям (хоть вы с этим и не согласны);
- проще организоваться пользователям для обхода такой защиты, выработать некий оптимальный алгоритм работы с сайтом - попросту "не долбите F5 каждые 5 секунд и не кликайте по ссылкам бездумно и будет вам сщастье на 20 человек за цену аккаунта на 1 человека".

В моём варианте все плюсы вашего метода - мои минусы, а "ваши" минусы - мои плюсы.

Antonariyuser7320Насчёт аджаксов. Есть страница, которая обновляет своё основное содержимое (большой раздел в теле HTML-документа) одним аджаксом. Это на что-то влияет? Разве аджакс-запрос не такой же, как и обычный?Да, он не такой как обычно. При асинхронном обновлении целой страницы обычно ее блокируют, чтобы не было возможности сделать еще один асинхронный запрос до окончания обновления. Принципиальной разницы с синхронным обновлением тут нет.
Эмм... У меня не целая страница, а просто большой раздел. Скажем так, большая статья приходит аджаксом и заполняет собой бланк (заголовки с пустыми абзацами; в абзацы надо вставить текст из аджаксового JSON-объекта) на готовой странице. Просто по объёму этот текст превышает объём самой страницы-бланка, включая интерфейс сайта и прочие объекты из мастер-страницы.

Я спрашивал, делается ли аджакс-запрос так же, как и обычный в смысле отправки-приёма куки. Открыл в Википедии статьи по аджаксу и куки - нигде в статье про куки не втречается слово ajax, а в статье про аджакс - слово cookie (смотрел в английской Википедии). Ну я и сделал вывод, что эти запросы по отношению к куки выглядят одинаково с обычными запросами.

AntonariyНет. Я предлагаю накручивать счет пропорционально количеству запросов без каких-либо ограничений.
Ограничение вызовов лишь как альтернативный тарифный план для тех, кто ниасилил анлим.
Но всё равно считать запросы, да? С точки зрения основной части реализации это будет то же, что и ограничение по запросам - счётчик запросов.

Antonariyuser7320- проще реализовать - буквально счётчик типа counter++ с минимальной обвязкой;Не такой примитивный. Запрос, например, обновляющий куку, гораздо легче запроса, выводящего список из 100500 позиций. И поэтому вот это заявление:А в это время часики-то тикают и расходы-то идут.требует детального анализа.
По каким правилам вычисляются эти самые расходы? По этим же правилам нужно составлять тарифные планы и калькулировать счета, иначе никакой зависимости доходов от расходов не будет, и стопудоф возникнет ситуация, когда расходы взлетят до небес, а доходы упадут ниже плинтуса. И тебе это известно, именно с этой ситуацией ты пытаешься тут бороться, но совершенно не теми средствами.
Ну, для трудных запросов, выводящих кучу позиций - постраничный вывод с кешированием общего результата (в смысле, что без постраничности). Плюс ограничения, типа хранить этот общий результат всегда в кеше и обновлять его не более раза в единицу времени (сутки, час - как будет оптимальнее). Вобщем, это всё относится к оптимизации работы высоконагруженного сайта вообще, а не только к разработке оптимальных тарифов подписки.

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

Ну и в любом случае, если пока у меня сервис далеко даже не тысячная часть Ютуба (и никогда такой не станет), то мне об этом париться не придётся. Тем более, что я точно знаю, что в моей предметной области нет списков под 100500 позиций. От силы несколько сотен. Для первой реализации в качестве теста можно пока не заморачиваться всякими нюансами. Потом, конечно, буду дорабатывать.

AntonariyЕще раз говорю: продавать аккаунты — тупо при любом тарифном плане. Именно по причине выхода многими пользователями из-под одного аккаунта. Я предлагал прямо противоположное — никаких ограничений по аккаунтам, чем их больше, тем лучше, тем больше нагрузка и счет на оплату, вычисляемый по прозрачным и понятным пользователю правилам (которые таковыми нужно сделать). И тогда не нужна возня с куками — 10 пользователей под одним аккаунтом или десятью, какая разница? Счет капает одинаково.
Во-первых, вы предлагаете, как я понял, оплату после предоставления услуги? Или придётся заводить некий "счёт пользователя" и списывать с него деньги?

Во-вторых, как тогда идентифицировать пользователей? Тем более, если речь будет идти о счёте пользователя. Ну и идентификация нужна для того, чтобы (если без счёта) было кому предъявлять чек на оплату наших услуг.

Вобщем, без аккаунтов я не понимаю, как это всё вообще будет выглядеть.


Далее. Нас больше устроит вариант оплаты ДО предоставления услуги в любом случае - с аккаунтами или без, со счётчиком или с вознёй с куки.

AntonariyЭто сервис корпоративный или персональный? Я исходил из предположения, что корпоративный, а раз так, то сначала заводится аккаунт админа организации, а уж он по мере необходимости заводит аккаунты сотрудников. Ну и все аккаунты объединяются записью о юридическом лице, которому выставляются счета.

А если персональный, то я не вижу смысла в передаче аккауна и кук между разными юзерами.
Смешанный. И организациям, и отдельным физическим лицам будем предоставлять. Но организациям будем предоставлять ПОКА как отдельным физическим лицам - т. е. заказывают 20 подписок, получают 20 аккаунтов. Аккаунты, кстати, можно заводить самому на сайте - обычная регистрация. Только фактическое добавление услуги включается админом у меня на сервере. Это пока - пока клиентов мало. Потом как-то автоматизируем и совместим с платёжными системами. Но пока это только отработка самого сервиса и самой модели распространения, обкатка на нескольких заказчиках - можно и вручную с ними поработать.

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

Antonariyuser7320Но всё равно считать запросы, да?Грубо говоря. Я бы еще и траффик учитывал. Сто небольших запросов не тоже самое, что сто больших, если смотреть с точки зрения твоих расходов. Соответственно сто небольших запросов и клиенту должны обходиться дешевле.
Трафик - это опять непонятки и нервотрёпка для клиента.

Я ориентируюсь на модель подписок всяких сервисов, типа игровых (Xbox Live, PlayStation Plus) - они дают возможность выкачивать любые купленные игры любое количество раз. Хоть один раз, хоть десять - купил новую приставку или жёсткий диск старой поменял, и с того же аккаунта накачал себе все цифровые версии купленных игр.

Насколько я понял, секрет тут прост - с самого начала выставляется ценник, который с запасом покрывает среднестатистические затраты на использование сервиса одним пользователем. Ну и создаются ограничения на максимальные нагрузки - макс. скорость отдачи, макс. число запросов АПИ и прочее . После этого можно уже говорить об "неограниченном" использовании фактически ограниченного сервиса. Это как у провайдеров - анлим, но скорость всегда "до". Просто некоторые поступают альтернативно - анлим, но с "порогами" - высокая скорость всегда до порога, а после - хоть закачайся... на 128 кб/с. Вы (или кто-то другой, не помню), кстати, предлагали как раз второй вариант. А я выберу, пожалуй, первый вариант - буду резать всех пользователей в соответствии с возможностями железа и окупаемостью, но официально у меня будет как бы анлим. Тут в любом случае без первоначальных настроек через набор статистики не обойтись.

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

AntonariyAntonariyЯ бы еще и траффик учитывал.Причем это делается элементарно — реквест и респонс имеют IO.Stream, размер которого можно невозбранно выяснить.

Хотя ты наверное MVC используешь, не знаю, есть ли там возможность потеребить эти стримы.
Использую MVC - это просто надстройка над ASP.NET, грубо говоря. Т. е. MVC использует много чего из ASP.NET.

Если вы про это , то можно и размер входящих-выходящих потоков узнать.

авторТолько фактическое добавление услуги включается админом у меня на сервере.
Через редактор базы данных заказчиков.

автор Ну а мы на днях заметили попытки sql-инжекта в наш сервис, проверили ip — а это же наши заклятые друзья
Эскуэль заенджектить догадались, а свой айпи скрыть не догадались. Доморощенные кулхацкеры. Серьёзные люди найдут подход посерьёзнее. А так аккаунт позволить хоть немного в идентификации. Потому что обращаться к сервисным методам можно только будучи залогиненым. А аккаунт содержит в себе и инфу о клиенте более подробную (включая юридический адрес), чем просто какой-то айпи.

Ну а так-то я согласен, что серьёзно ломать нас начнут, только если мы кому-то дорогу перейдём - до чего ещё дожить надо.

авторИ клиенты у нас не передают друг другу аккаунты, хотя ни малейших препятствий этому нет. Обоснование элементарное — "я заплатил деньги, с хера ли делать кому-то подарок"?
На торрентах лежат МСДН-образы Студии, СКЛ Сервера и прочих вещей от МС. Чел купил, а там даже вводить ничего не надо - серийник вшит. Вот и вся защита. Почему он делает всем подарки?

Но вообще, мы же начали говорить о нужности-ненужности аккаунтов. Я же сказал, что надо как-то идентифицировать пользователя. Т. е. аккаунты нужны. Без них я просто не вижу варианта - хоть вызовы АПИ продавай, хоть трафик, хоть с куки мути.

Antonariyuser7320 Насколько я понял, секрет тут прост - с самого начала выставляется ценник, который с запасом покрывает среднестатистические затраты на использование сервиса одним пользователем.И одному пользователю это автоматически становится невыгодно. Хотя это зависит от конечного размера ценника. Если он в пределах 500р в месяц, то это копейки, никто не будет заниматься мухлеванием с логинами.
Сониевская или МСовская подписка стоят 50-60 баксов в год. На аккаунтах есть какие-то послабления, типа шаринга игры между тремя-четырьмя "друзьями" или "членами семьи". Пользователи этим пользуются и пытаются организовываться для покупки игр "вскладчину" - ты купил одну игру, Вася - другую, а я - третью. Потом "подружились" все и расшарили между собой все купленные игры. Что-то типа такого. Это позоляет покупать игры в разы дешевле. Вроде как... Всё это только для того я написал, чтобы показать, что пользователи будут выкручиваться, придумывать, изобретать разные схемы, чтобы сэкономить хотя бы 2000 рублей в год. Хотя по факту, им, может, выгоднее было бы забить и купить, а сэкономленное время потратить на самообразование, обновление мощностей и, как итог, увеличение доходов.

Antonariyuser7320 Трафик - это опять непонятки и нервотрёпка для клиента.Как же провайдеры работают? :) Это же чудовищно запутанная схема — 20гб на скорости 5мб/с, с последующим урезанием до 0,5
Такие тарифы непопулярны у провайдеров. Пользователям по душе "честный анлим", пусть и на скоростях, меньших, чем заявленные. Ну и заявленные все уже привыкли писать-воспринимать как "до".

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

AntonariyИ подумай еще вот о чем: корпоративные и персональные тарифные планы сильно отличаются как по деньгам так и по принципам подсчета. Для персональных удобно использовать абонентскую плату, то есть схему, к которой склоняешься ты, так как мало шансов, что пользователь передаст аккаунт другому пользователю. И для защиты от одновременной работы достаточно прибивать старую сессию — шанс, что два независимых пользователя будут кооперироваться и мудрить с куками пренебрежительно мал. А для корпоративщиков больше подходит моя, независимая от количества и передачи аккаунтов.
А защита от того, чтобы корпоративщики (юридические лица - юрики) не покупали аккаунты для физических лиц (физиков) - только закон? Можете вы предложить что-нибудь вдобавок к закону, работающее побыстрее закона?

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

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

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

Минус моей схемы с куками, что у меня пока только один уровень аккаунтов - нет неких корпоративных аккаунтов, в которых может быть множество подаккаунтов. Поэтому, при покупке организацией, скажем, 20 аккаунтов у меня, мне придётся сгенерить 20 аккаунтов, внести их в БД и отдать их организации. При этом получится, что все эти аккаунты будут иметь один набор реквизитов. Т. е. придётся переделывать схему пользовательских профайлов. А со счётчиками и корпоративными аккаунтами можно выдать один аккаунт на всех сотрудников организации.

как-то так...Все не читал... При авторизации запись в бд к пользователю мд5 сессион ид + юзер агент... При следующих запросах сверяемся... УСПЕХОВ!
Я это пока и делаю - в куки пользователю некий идентификатор, плюс в БД на сервере этот же идентификатор. При запросах сверяю, да плюс ещё идентификаторы часто меняю. Мы сейчас уже детали этого всего обсуджаем и стоит ли это вообще делать, а не заменить чем-нибудь.

Сделал немного не так, как в алгоритме по ссылке в первом посте, но почти так - просто сказались детали реализации. Шагов оказалось раза в два больше - пришлось всякие sentinel-переменные ввести, задействовать 5 штук переменных в профайле. Вобщем, как я и хотел - отсылает на перелогинивание, если нарушены куки. Плюс ввёл механизм "прощений" - когда за определённый промежуток времени прощается определённое количество нарушений куки - на всякие форс-мажоры и простительную смену браузера (домой пришёл с работы или наоборот, например). Когда прощения превышены - тогда отправляет на перелогинивание. При этом логирование прикрутил - выделил четыре основных причины нарушений (три явных способа нарушения куки и "всё остальное") и логирую, соответственно комментируя, по какой причине отправил на перелогинивание.

Всё сделано в виде ActionFilterAttribute - т. е. можно прикручивать эту "защиту" выборочно к контроллерам или действиям.

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

Теперь полирнуть и выкачу на более серьёзные испытания временем.

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