Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
Извиняюсь за повтор темы. Но в теме "Программирование" что-то не отвечают. Может, потому, что я не ASP.NET'чиков спросил. Тут, наверное, лучше будет. У меня вопрос: будет ли работать представленный ниже по ссылке алгоритм. Точнее, я бы хотел, чтобы кто-нибудь нашёл способ его сломать. http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1075109&msg=15725902 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2014, 08:07 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
Я клиенту внедрил сниффер и получил полный запрос и ответ (заголовки + данные), то есть куки, user-agent и прочее. У себя на компьютере делаю идентичный запрос на сервер. Сервер естественно меня принимает за своего. Меняю пароли, списываю бабосы со счетов, в общем делаю всё что хочу. Каким образом та система защитит от этого? Запросы идентичны - и куки и браузер (юзер-агент) и ОС и т.д. Единственное, что не подменишь - это ip-адрес (слепой спуффинг оставим на теоретических началах), отсюда - единственное, к чему можно привязаться - это ip. Второе - все важные действия, такие как смена пароля, оплата и прочее имеют как минимум две ступени защиты, то есть например без получения кода на телефон (СМС), пользователь не может ничего оплатить или совершить какие-нибудь серьёзные действия и тогда кража кук не приведёт к краху аккаунта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2014, 14:41 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
st_stЯ клиенту внедрил сниффер и получил полный запрос и ответ (заголовки + данные), то есть куки, user-agent и прочее. У себя на компьютере делаю идентичный запрос на сервер. Сервер естественно меня принимает за своего. Меняю пароли, списываю бабосы со счетов, в общем делаю всё что хочу. Каким образом та система защитит от этого? Запросы идентичны - и куки и браузер (юзер-агент) и ОС и т.д. Единственное, что не подменишь - это ip-адрес (слепой спуффинг оставим на теоретических началах), отсюда - единственное, к чему можно привязаться - это ip. Второе - все важные действия, такие как смена пароля, оплата и прочее имеют как минимум две ступени защиты, то есть например без получения кода на телефон (СМС), пользователь не может ничего оплатить или совершить какие-нибудь серьёзные действия и тогда кража кук не приведёт к краху аккаунта. Вот, это уже лучше! Хотя бы обсуждение началось. А то все молчат... Сниффер - это понятно. Так можно сказать, что внедрил клиенту паяльник... дальше не буду. Про подтверждение всяких важных действий по СМС и т. п. - это тоже понятно. Это я согласен. Про айпи - это тоже всё сменяемо. Я начитался по способам создания "слепков" с браузера и системы пользователя - всё это фигня. Просто потому, что можно иметь свой прокси и подменять что угодно на что угодно. На самом деле, задача моей защиты - недопустить, чтобы под одной учёткой работало более одного пользователя. Всё. Я выяснил, что добиться этого нельзя. Но можно приблизиться к этому. Т. е. клиент может пользоваться одной учёткой одновременно с нескольких браузеров, но я должен сделать так, чтобы это было настолько неудобно, что он бы захотел оставить эту затею. Я придумал алгоритм, который фактически заставляет постоянно перелогиниваться, если учётка используется с разных браузеров. Основано всё на банальной частой смене некоего значения в куки, которое дублируется на сервере и при каждом запросе проверяется. Обычный клиент бы просто раз залогинился в новом браузере и всё. Если перешёл на другой браузер - на старом снова приходится залогиниваться. Если не переходит - работает на старом и дальше. Вот и всё. И меня интересует, какие есть способы обхода этого? Я там по ссылке разобрал вариант с подменой куки. Вроде, мой алгоритм это нормально отрабатывает, если не применена автоматизация по синхронизации куки всех используемых браузеров, что является довольно экзотическим вариантом (т. е. 99% клиентов явно не будут этим заморачиваться при небольшой цене пользования подпиской на веб-приложения). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2014, 15:38 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
Т. е. это не система защиты данных клиента от снифферов или ещё чего. Это система защиты нас от недобросовестных клиентов ("пиратов", так сказать). Клиенты будут защищаться... ну, пока шифрованных каналом (обычный SSL) и тем, что вы сказали - подтверждение важных действий альтернативными методами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2014, 15:41 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
Я на работе с утра до вечера на одном браузере, дома вечером на другом, на телефоне иногда в течении дня - на третем. Если меня будет постоянно разлогинивать, то я возненавижу данный сайт. Это больше не защита, а раздражение пользователя. Про подмену ip приведу пример - пользователь подключен к провайдеру, ему выдан ip 188.150.210.120 (взял наугад). Попробуйте с этого ip добавить сообщение на форуме, не врезаясь в подъезде в сетевой кабель клиента. Можете использовать свои прокси или как их там. > На самом деле, задача моей защиты - недопустить, чтобы под одной учёткой работало более одного пользователя. Зачем ставить непонятные запреты пользователю от мифических пиратов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2014, 16:14 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
p.s. а куда народ подевался - skyANA, hVostt, МСУ? Уже месяц сидим без срача, непорядок ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2014, 16:20 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
st_stp.s. а куда народ подевался - skyANA, hVostt, МСУ? Уже месяц сидим без срача, непорядок Тута мы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2014, 18:16 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
st_stЯ на работе с утра до вечера на одном браузере, дома вечером на другом, на телефоне иногда в течении дня - на третем. Если меня будет постоянно разлогинивать, то я возненавижу данный сайт. Это больше не защита, а раздражение пользователя. Про подмену ip приведу пример - пользователь подключен к провайдеру, ему выдан ip 188.150.210.120 (взял наугад). Попробуйте с этого ip добавить сообщение на форуме, не врезаясь в подъезде в сетевой кабель клиента. Можете использовать свои прокси или как их там. > На самом деле, задача моей защиты - недопустить, чтобы под одной учёткой работало более одного пользователя. Зачем ставить непонятные запреты пользователю от мифических пиратов? Согласен про неудобства. Я буду думать над этим. Возможный вариант решения в спойлере ниже. А что, если я добавлю возможность работать сразу с нескольких браузеров? Скажем, не более 5. Или лучше сказать, будет счётчик подряд идущих несовпадений куки, который и будет говорить, что работа идёт как минимум с двух браузеров с постоянными несовпадениями. Тогда сценарий нормального пользователя такой: поработал дома, поработал на работе, поработал со смартфона, потом опять дома. Всего должно быть 4 подряд идущих несовпадения. А сценарий для нечестного пользователя такой: двое с двух браузеров работают одновременно, и подряд идущие несовпадения нарастают очень быстро. Вот таких хитрюг надо отрезать. В смысле, портить им жизнь постоянными залогиниваниями. Как вам такое ход? Про айпи это не выход. У некоторых провайдеров динамические айпи, меняющиеся после переподключения пользователя. Плюс пользователи могут сидеть за прокси (корпоративный, местной локалки подъезда, сотового оператора - да какого угодно). Вобщем, привязка к айпи это как привязка к одному рабочему месту - ещё хуже, чем моя затея с постоянными перелогиниваниями. Я тут не вижу пока решения с айпи. Про пиратов. Это я не пользователя от пиратов защищаю, а нас от пользователей-пиратов. Купил, допустим, пользователь у нас одну копию, получил одну учётку. А раздал всем сотрудникам на предприятии. И ладно, если это 3-5 человек. А если 30-50? Мы на одной поддержке оборудования для работы с такой толпой (а они же не единственные клиенты у нас будут) не окупимся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2014, 19:45 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
Привязка к ip это защита пользователя при краже кук. У вас же как я понял из последнего сообщения - защить себя (чтобы юзеры не продавали свои аккаунты), а не пользователя. Посмотрите в сторону usb-токенов . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2014, 07:59 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
user7320На самом деле, задача моей защиты - недопустить, чтобы под одной учёткой работало более одного пользователя. Всё. И зачем для этого такой огород? Решение элементарное и ископаемое: при повторной авторизации закрывать первую сессию. Второй юзер заходит, первый вылетает. Всё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2014, 10:58 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
А мы один раз только залогинимся. Главный юзер авторизуется, получает куку, тут же программно автоматом копирует эту куку по всем браузерам предприятия и работаем в количестве 50 человек под одним аккаунтом. Сессию (если она есть) просто продлеваем редкими автоматическими запросами. Смысл в другом - городить это у себя на предприятии никто не станет, хотя вариант и возможен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2014, 13:00 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
st_stА мы один раз только залогинимся. Главный юзер авторизуется, получает куку, тут же программно автоматом копирует эту куку по всем браузерам предприятия и работаем в количестве 50 человек под одним аккаунтом. Сессию (если она есть) просто продлеваем редкими автоматическими запросами. Смысл в другом - городить это у себя на предприятии никто не станет, хотя вариант и возможен.вариант возможен, если дополнить его хождением через один ip в общем, прострелить себе ногу тут возможно только если специально в нее целиться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2014, 13:41 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
user7320Это я не пользователя от пиратов защищаю, а нас от пользователей-пиратов. Купил, допустим, пользователь у нас одну копию, получил одну учётку. А раздал всем сотрудникам на предприятии. И ладно, если это 3-5 человек. А если 30-50? Мы на одной поддержке оборудования для работы с такой толпой (а они же не единственные клиенты у нас будут) не окупимся.так вот в чем проблема, не заметил сразу. тогда это стрельба в ногу разработчику :) st_st Посмотрите в сторону usb-токенов.тоже, выходит, не вариант. достаточно одного токена, воткнутого в сервер терминалов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2014, 13:51 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
такие проблемы нужно решать юридически, а не технически. собрать факты нарушения лицензионного соглашения и пригрозить судом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2014, 13:53 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
st_stПривязка к ip это защита пользователя при краже кук. У вас же как я понял из последнего сообщения - защить себя (чтобы юзеры не продавали свои аккаунты), а не пользователя. Посмотрите в сторону usb-токенов . Мы от подобных токенов наоборот, отказаться хотим. st_stА мы один раз только залогинимся. Главный юзер авторизуется, получает куку, тут же программно автоматом копирует эту куку по всем браузерам предприятия и работаем в количестве 50 человек под одним аккаунтом. Сессию (если она есть) просто продлеваем редкими автоматическими запросами. Смысл в другом - городить это у себя на предприятии никто не станет, хотя вариант и возможен. Я это и имел ввиду под синхронизацией куки между браузерами пользователей. Такая штука, естественно, сломает мою защиту. Только я тоже на то и рассчитывал, что городить это у себя никто не станет. Antonariyuser7320На самом деле, задача моей защиты - недопустить, чтобы под одной учёткой работало более одного пользователя. Всё. И зачем для этого такой огород? Решение элементарное и ископаемое: при повторной авторизации закрывать первую сессию. Второй юзер заходит, первый вылетает. Всё. Как я распознаю, где первый, а где второй? По айди сессии? Так это всё в куки хранится - легко скопировать или подделать. Причём достаточно скопировать один раз. А при постоянной смене куки их надо копировать постоянно. Кроме того, как мне закрыть сессию предыдущего пользователя, когда ко мне послал запрос следующий? Если что, я использую FormsAuthentication. Antonariyтакие проблемы нужно решать юридически, а не технически. собрать факты нарушения лицензионного соглашения и пригрозить судом. Юридически - это понятно. Осталось только собрать факты ))) А в это время часики-то тикают и расходы-то идут. И при этом всё должно выглядеть цивильно, а не скандал с обрубанием сервиса пользователю. Лучше заранее предупредить, что частая смена браузера приведёт к перелогиниваю, и в лиц. соглашение это. Ещё раз пишу, что можно несколько раз подряд идущих несовпадений куки пропускать - пусть это будет поправка на смену пользователем браузера в течении рабочего дня. Раз 10 пропустить. Теперь добавим сюда (это я щас придумал), что число подряд идущих несовпадений будет обнуляться, скажем, каждый час. В результате получим, что нормальный пользователь может даже не заметить работы системы и система не будет его спрашивать перелогиниться вообще никогда. А вот когда хотя бы двое начинают работать под одним акком одновременно, то лимит несовпадений быстро исчерпается и пойдут запросы на перелогинивание. Каково, а? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2014, 14:27 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
авторЕсли что, я использую FormsAuthentication. Но это только для залогинивания на сайте и создания сессии на сайте. А для защиты и использую самописный ActionFilter, который усиленно юзает Profile. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2014, 14:32 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
user7320авторЕсли что, я использую FormsAuthentication. Но это только для залогинивания на сайте и создания сессии на сайте. А для защиты и использую самописный ActionFilter, который усиленно юзает Profile. Потому что такая защита должна работать только на определённых контроллерах и действиях, а не на всём сайте целиком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2014, 14:32 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
user7320И при этом всё должно выглядеть цивильно, а не скандал с обрубанием сервиса пользователюКакой скандал? Пользователь перво-наперво предупреждается, что факты нарушения зафиксированы, и если не прекратятся, то дело пойдет дальше. user7320А в это время часики-то тикают и расходы-то идут.А расходы оплачивает клиент через суд, если не удалось его образумить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2014, 14:47 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
Лимит вызовов назовём это API-методами сервера в сутки из-под одного клиентского аккаунта не вариант? При превышении лимита - либо платно вызовы сверх нормы, либо письмо клиента с объяснением зачем ему нужно больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2014, 14:48 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
Antonariyтоже, выходит, не вариант. достаточно одного токена, воткнутого в сервер терминалов. Везде засада. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2014, 14:49 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
Antonariyuser7320И при этом всё должно выглядеть цивильно, а не скандал с обрубанием сервиса пользователюКакой скандал? Пользователь перво-наперво предупреждается, что факты нарушения зафиксированы, и если не прекратятся, то дело пойдет дальше. Как минимум, для доказательства нужна подобная схема, что я обрисовал - нужно же как-то определять, что работа идёт с кучи браузеров под одним аккаунтом. Но и тут есть минус - перед кем доказывать? Подряд идущие совпадения куки явно не являются юридически доказательством. Моя схема - не признанная экспертами и наверняка имеет изъяны. Это для внутреннего пользования. Antonariyuser7320А в это время часики-то тикают и расходы-то идут.А расходы оплачивает клиент через суд, если не удалось его образумить. Когда дело дойдёт до суда - согласен. Только опять же, суд - это непредпочтительный вариант. Предпочтительный - чтобы всё происходило тихо-мирно. Желательно, в автоматическом режиме. st_stЛимит вызовов назовём это API-методами сервера в сутки из-под одного клиентского аккаунта не вариант? При превышении лимита - либо платно вызовы сверх нормы, либо письмо клиента с объяснением зачем ему нужно больше. В принципе, вариант. Тоже можно через фильтр и поставить эти фильтры только на те методы, которые критичны. Чтобы всякие подгрузки картинок интерфейса не считались за вызовы АПИ. Вроде, схема простейшая - увеличивай счётчик при каждом ображении и всё. Гораздо проще, чем у меня. Но тут тоже есть минус - придётся анализировать работу всех действий контроллеров всего сайта. Может, там при одних сценариях работы вызовы интенсивно используются, а при других - за час только 20 раз... Хотя, можно просто взять с запасом в разы. Я это и раньше обсуждал (в той теме по ссылке в первом сообщении этой темы). Минус - трудно презентовать такую монетизацию заказчикам. "Количество вызовов АПИ" - не очень понятная схема для простых людей. Это не техспециалисты - мы им не АПИ продаём. Это готовые веб-приложения. Это что, на кнопочки много жать не надо? Начнут придумывать стратегии экономичного пожатия кнопочек... Вобщем, выглядит как-то глупо перед простыми клиентами, хотя для техспециалиста вполне себе нормально. Я оставлю это на запасной вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2014, 06:24 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
Судя по неуверенным комментариям (что здесь, что в теме по ссылке в первом посте), народ либо такого никогда не делал, либо, действительно, продавал вызовы АПИ или с токенами. Или заводил счёт для клиента, где клиент расходовал свои деньги на каждое действие ("тратящийся ресурс"). Либо просто неограниченная подписка на использование за фиксированную плату - но это уже только для крупных контор, наверное, которые могут себе это позволить (как МС, например). Неужели я первый? Однако, непонятно, как работает тот же Офис 365 у Майкрософт. Который на ХТМЛе сделан и через браузер работает. Неужели один логин-пароль и никакой привязки к браузеру, железу и т. п.? Фактически, бесплатная рекламная версия (купил раз и раздал всем) для заманивания на десктопный вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2014, 06:41 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
Я вот сейчас при запросах данных с чужого сайта использую подобные API с ограничениями на количество вызовов в сутки. API делится на платные и бесплатные. Если нужно увеличить количество вызовов, то в личном кабинете прям рядом с ограничением есть кнопка запроса увеличения и поле комментария почему хочу увеличить. В настройках аккаунта могу привязать ip-адреса, с которых возможен вызов, а также есть полная статистика. Каждый вызов API-методов подписываю ключом. Продавать свой ключ другим смысла нет, попадёшь на бабосы за чужие вызовы. Если есть подозрения, что кто-то другой пользуется, то ограничиваю ip-адреса/меняю пароли/ключи. Чужой сервер тоже бабосы свои получает, все довольны и нет никаких супермеганикомунепонятных алгоритмов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2014, 14:02 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
user7320 Судя по неуверенным комментариям (что здесь, что в теме по ссылке в первом посте), народ либо такого никогда не делалТы как-то мудрено там все расписал, но если суть в том, чтобы менять куку при каждом запросе, то я так собирался сделать, но не стал, потому что это не будет работать при использовании ajax. Допустим, ты сделал один ajax-запрос с валидной кукой, и, не дожидаясь ответа, второй запрос. Первый запрос на сервере отработал, поменял куку, и тут приходит второй запрос, а кука-то у него старая — запрос обломался. Единственный беспроигрышный вариант — продавать не логины, а ровно то, по чему у тебя "тикают часики" и идут расходы, — нагрузку. То есть некую величину, вычисляемую из количества запросов в период времени и, возможно, траффика. Как киловатт-часы. И влепить на страничку нагружометр по аналогии с крутящимся диском счетчика. Тогда количество логинов не имеет значения. При этой схеме пользователю все понятно и финансово прозрачно, а мимо тебя не проскочит и копейка. Однако под это дело нужна толковая математическая модель, которую лично я пока не представляю. При твоей же схеме, даже если ты нашел защиту от пиратов, возможен вариант, когда запускается скрипт, юзающий единственный легальный логин и производящий нагрузку как дюжина пользователей. Часики тикают, расходы идут, а предъявить клиенту нечего — все в рамках соглашения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2014, 14:09 |
|
||
|
Будет ли работать такая схема?
|
|||
|---|---|---|---|
|
#18+
Antonariyuser7320 Судя по неуверенным комментариям (что здесь, что в теме по ссылке в первом посте), народ либо такого никогда не делалТы как-то мудрено там все расписал, но если суть в том, чтобы менять куку при каждом запросе, то я так собирался сделать, но не стал, потому что это не будет работать при использовании ajax. Допустим, ты сделал один ajax-запрос с валидной кукой, и, не дожидаясь ответа, второй запрос. Первый запрос на сервере отработал, поменял куку, и тут приходит второй запрос, а кука-то у него старая — запрос обломался. А если ввести счётчик невалидных куки и "прощать" пользователю некое число, которое можно объяснить аджаксами, задержками и прочими непредвиденными обстоятельствами? Скажем, 10. Тогда один пользователь сможет нормально работать и с аджаксами, а двое сразу быстро выберут лимит десятки. Ну и счётчик обнулять периодически. В конкретной реализации можно поиграть значениями (сколько прощать, через сколько обнулять). Ну и, естественно, дизайн приложения делать такой, чтобы самому себе не отправлять подряд по 10 аджаксов. А? AntonariyПри твоей же схеме, даже если ты нашел защиту от пиратов, возможен вариант, когда запускается скрипт, юзающий единственный легальный логин и производящий нагрузку как дюжина пользователей. Часики тикают, расходы идут, а предъявить клиенту нечего — все в рамках соглашения. Это уже на сервере надо ограничивать число запросов в секунду. Вроде, это и в IIS встроенное есть. И не только в IIS. И это вообще относится ко всем сайтам, а не только к защите подписочных сервисов - так можно любой сайт за'DDOS'ить. AntonariyЕдинственный беспроигрышный вариант — продавать не логины, а ровно то, по чему у тебя "тикают часики" и идут расходы, — нагрузку. То есть некую величину, вычисляемую из количества запросов в период времени и, возможно, траффика. Как киловатт-часы. И влепить на страничку нагружометр по аналогии с крутящимся диском счетчика. Тогда количество логинов не имеет значения. При этой схеме пользователю все понятно и финансово прозрачно, а мимо тебя не проскочит и копейка. Однако под это дело нужна толковая математическая модель, которую лично я пока не представляю. Кроме вами названного, тут минус ещё и тот же, что я раньше описывал - такая схема монетизации для простого пользователя слишком новая и непонятная. Людям не нравится, когда их на счётчик посекундный ставят (счётчик же будет обновляться буквально после каждого запроса). Это жутко нервирует. Как интернет с повременной оплатой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2014, 15:12 |
|
||
|
|

start [/forum/topic.php?fid=18&msg=38589503&tid=1357364]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
69ms |
get tp. blocked users: |
2ms |
| others: | 241ms |
| total: | 386ms |

| 0 / 0 |
