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 - т. е. можно прикручивать эту "защиту" выборочно к контроллерам или действиям.

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

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

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