BiTel

Доброго времени суток!

Очень хотелось бы иметь следующий функционал:

При открытии клиентом странички домашнего кабинета, он (то есть -
кабинет) ищет IP адрес клиента среди онлайн пользователей (тут нужно
исключить залипшие сессии) и:
1) если находит, то пускает на сайт под соответствующим логином без
авторизации
2) если не находит, то показывает страничку авторизации

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

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

Хотел даже начать переговоры с разработчиками о доработке, но тут вспомнил про подмену reject-а accept-ом при отрицательном балансе. Такие пользователи в биллинге считаются в оффлайне и получается, что клиент не попадет в свой домашний кабинет тогда когда он ему особенно нужен! Значит доработка потребует серьезных изменений в коде и разработчики скорее всего откажут...

Но фича кажется очень заманчивой!

очень сомнительная фича ..т.е от соседа я не смогу зайти под своим логин/паролем
а reject- to accept как раз был сдела чтобы получить доступ к личному кабинету при отрицательном балансе

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

А вот про reject/accept я что-то не понял...

Фича реально использовалась раньше нами на самописном биллинге и клиенты были весьма довольны... Ну не хотят люди ничего запоминать!!! а удобство - одно из конкурентных преимуществ

а понял я что Вы хотели сказать про reject/accept:

проблема не в том, что клиент не может попасть в свой домашний кабинет - проблема, в том, что он НЕ ХОЧЕТ помнить свой логин/пароль или не знает что это такое

зачем вам вообще тогда авторизация по логину/паролю ? вам тогда нужна авторизация по порту или схема отдельный vlan на клиента ..Правда доступа к статистике безпарольного у них пока все равно не будет ..

Это Вы мне предлагаете менять практически все а не все оборудование в моем зоопарке поддерживает нужные технологии, да PPPoE удобен и по многим другим причинам, плюс есть существующие и уже настроенные клиенты...
То что есть у нас сейчас имеет вполне четкие материально/технические обоснования и данный момент изменения не целесообразны, да и Вы же сами говорите поставленной-то проблемы все равно не решить
Клиент уже в онлайне у него все работает, проблемы его подключить, аутентифицировать, посчитать его траффик и т.д. нет. Проблема начинается там где клиент хочет посмотреть сколько скачал, сколько денег на балансе, хочет пополнить баланс картой и т.д. но при этом не хочет ничего запоминать (кто платит тот и заказывает музыку). Причем тут авторизация по порту?
Упрощенная авторизация в веб интерфейсе ПОЛНОСТЬЮ решила бы все эти проблемы! И я готов оплатить разработку (если конечно цифра в разумных пределах , если только Вы согласитесь и мы сможем что-нибудь придумать с reject/accept клиентами...

Все современные браузеры умеют запоминать введенный логин и пароль, так что для клиента это практический ОДНОРАЗОВЫЙ напряг найти договор и ввести их...
А вот если кабинет будет доступен без пароль и отец например не хочет, что бы сынишка туда лазил без его ведома - то будет ай-я-яй

кхм, как Вам сказать... есть много УЖЕ работающих клиентов, с которыми одноразово придется очень многоразово напрячься техподдержке, что уже происходит и как показывает практика... ну не катит это

Выглядит это так: я простой домохозяйка/шахтер/таксист/слесарь пришел домой включил мааленькую такую штучку (говорят модем называется), набираю одноклассники.ру а мне там говорят "деньги на балансе кончились идите в домашний кабинет", тыкаю ссылочку а там меня спрашивают про какой-то логин и пароль. Это когда вам надо узнать есть ли у меня деньги или нет вы меня узнаете, а как в кабинет пущать какой-то логин хотите? Ну что человеку скажешь? Ведь логично...

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

Хотелось бы завернуть беседу в другую сторону: кто-нибудь из пользователей системы хотел бы такое? К разработчикам - возможно ли такое в принципе или мне даже думать об этом не надо? А если возможно - что делать с reject/accept?

Спасибо заранее!

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

Было бы очень удобно.
Как вариант - собственная функция (скрипт) авторизации.
На входе функции - IP удаленный, строка запроса, con.
На выходе функции - под каким именем пустить.
Если она не пропускает (на выходе null) - переход на стандартную страницу входа (имя-пароль).
Тогда можно и от параметров "плясать". Например, группа для которой разрешена упрощенная авторизация.
Как вариант - в конфигурации кроме модуля авторизации указать имя этой функции.

Техподдержке было бы на много удобнее. Да и клиентам тоже. Телефон бы отдохнул...

Да-да-да... о том и я

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

должен знать это Вы хорошо сказали... учить их тоже сами будете?
Как показывает практика (кто-нибудь сможет возразить?) люди выбирают всегда что-попроще и где не надо ничего быть ДОЛЖНЫМ знать так возникли авто с автоматом, виндовс с тупым но простым интерфейсом, языки программирования отличные от ассемблера (я кстати его очень уважаю) и т.д.
Если Вы пишете тексты только в VI, сайты смотрите только набивая в телнете HTTP запросы и никогда не пользуетесь DNS'ом, знайте - от меня Вам респект и уважуха, но таких среди наших абонентов НЕТ.
Насчет спуфинга.... уфф... во первых ничего не взламываемого в интернете нет и это тоже из мировой практики есть только мониторинг, сбор логов и в результате соответствующая ответственность лица.... Даже если кто-то подберет IP к чужому домашнему кабинету... что с того? Он увидит мега секретную информацию об используемом тарифе? И что ему с этого будет? Логин он не стырит так как не знает текущего пароля... разве что навредничает - сделает смену тарифа Чтобы словить кайф он должен делать это массово - тогда мы его вычислим и тогда....
Итак, что атакующий получит? Если ничего - тогда и атаковать не зачем Вы будете грабить банк, который без охраны и в котором нет денег

Наш абонент всегда должен иметь доступ в свой кабинет, чтобы посмотреть баланс, добавить себе денег и посмотреть когда и сколько он насидел. И еще сменить тариф.

Вот это действительно важно!

массово сменит всем популярные нынче анлимы на тариф где считается трафик и пока Вы будете ловить шутника Ваша ТП будет разгребать тонны звонков от возмущенных абонентов у которых почему-то израсходовались все $ на счету, а когда ТП узнает что это произошло из за "нужной" багофичи, то домой Вам лучше ходить в светлое время суток

ну хорошо... мне нравится направление нашей беседы - мы не спорим что фишка нужная, мы обсуждаем детали ее внедрения
чтобы исключить игры с тарифными планами, в принципе, можно при смене тарифа дополнительно спрашивать пароль какого-нибудь модуля и тем, кому надо менять тариф через веб, уж придется запомнить пароль... а лучше просто сделать при смене тарифа запуск внешнего скрипта, с помошью которого провайдер может извещать абонента смской о произведенных изменениях и т.д.
Для меня например вообще не существует этой проблемы так как смена тарифа у меня делается по звонку в офис, т.е. я готов одну фичу поменять на другую.
Вообще меня удивляет, что мы приняли без возмущения со стороны разработчиков, что их веб серверу так легко скормит любой IP! А что сверять с remote ip tcp соединения не надо? Это наводит на опасные мысли - может тогда и защиты от sql инекций нет?...
Сомневаюсь однако, что все так просто.

Хм... внезапно понял, что фича которая мне нужна, частично в биллинге есть
называется tray info что ж никто не подсказал? цитирую:
"позволяет осуществлять мгновенный доступ к странице статистики, скрывая от пользователя процесс авторизации"
только вот ее настройка уж очень сложна для большинства наших абонентов, да и вначале вход в кабинет требуется для получения PIN-а. Но если преднастроить пачку таких утилит, дать их тех поддержке, чтобы она выдавала их пользователям... можно что-нибудь придумать.... буду работать в этом направлении.
Вообщем, спасибо всем принимавшим участие в дискуссии, если у кого будут еще какие-нибудь мысли на данную тему - буду очень рад, так как тема для меня актуальная.

а если сделать вариант что-то в духе такого: юзер идет на страницу bill.provider.ru, на которой висит скрипт, например на похапе, который "смотрит" адрес клиента, берет из базы его логин и пасс и POST-ит их на страницу статистики stat.provider.ru после чего делает туда редирект ... ну или скрипт вообще висит на stat.provider.ru и отрабатвает только при запросе stat.provider.ru/ после чего опять же берет логин/пасс юзера, постит их в форму на stat.provider.ru/bgbillng/webexecuter ... как именно оно будет работать и будет ли работать вообще - я ХЗ, но для юзера все будет полностью прозрачно, что и требовалось ...

ммм... интересная мысль, можно все сделать и без доработки биллинга. Спасибо за совет!

а что там сложного? вбить два пина в диалог настройки?)
Можете сами генерить пины и выдавать их юзеру на бумажке, тогда не надо входить в кабинет.

_________________
I'm clever. I've got a computer.

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

Сделал... у меня авторизация в домашний кабинет идет по логину dialup модуля, но авторизация по паролю статистики не отключена (хотя и не предлагается), поэтому я сделал так:
клиент будучи в онлайне заходит на страничку: cabinet.provider.net там его встречает скрипт, который ищет его IP среди сессий, для которых исправно идут accounting update пакеты (так исключаем зависшие сессии):

select `lid` from `log_session_1_200911` where `ipaddr`=".$ip_addr_d." and `session_stop`>=now() - interval 5 minute and `session_stop` = (select max(`session_stop`) from `log_session_1_200911` where `ipaddr`=".$ip_addr_d." and `session_stop`>=now() - interval 5 minute)

если таковые имеются, то используя полученный login_id получаю номер договора и пароль статистики:

select `title`, `pswd` from `contract` where `id` = (select `cid` from `user_login_1` where `id`=".$login_id.")

потом выдаю пользователю редирект:

print "<meta http-equiv=\"refresh\" content=\"0;url=http://billing.provider.net/bgbilling/webexecuter?midAuth=0&pswd=".$web_pass."&user=".$contract_name."\"/>";

В результате пользователь попадает авторизованным в домашний кабинет, а если произойдет какая-то ошибка или подобрав IP, доступ к чужому кабинету получит кто-то чужой, то в URL он увидит только пароль статистики, а чтобы сменить пароль на интернет нужно знать именно пароль dialup модуля, так что аккаунт не будет украдет

Все отлично работает, только вот все это... бессмысленно ! Так как домашний кабинет больше всего нужен, когда кончились деньги и отключился интернет. А в этом случае если биллинг и выдаст accept вместо reject, то все равно не создаст сессию, и самое главное -не будет принимать update пакеты для этой сессии и ее обновлять. Так что таблица dialup_reject_to_accept_<mid> тут не выход - она не обновляется. Ну и что ж, что кто-то зашел с IP адреса, которому биллинг полчаса назад выдал accept вместо reject'а - не факт, что тот, кому адрес был выдан до сих пор в онлайне, а это - не злоумышленник...

Вопрос опять открыт.

т.е. вариант:
выдавая IP адреса "абы лишь бы клиент попал на статистику" записать его (IP) и время входа ручками в какую нить таблицу БД ну и чистить их оттуда по условию "время >= session-timout" чтоб небыло просроченных сессий ("левых" пассажиров), но зато клиент мог "прозрачно" входить на статистику
не рассматривался в принципе?

Так на основе чего принимать решение чистить или нет? Делать whois на BRAS?
Клиент мог дисконнектнутся не только по session-timeot... и мог раньше session-timeot...

может нарисовать скрипт на биншелле который будет проверять висит юзер на NAS-е или нет используя API (если там это есть) и запускать его по таймеру, а уже в скрипте принимать решение об удалении записи о юзере из временной БД или нет? даже не знаю ... вариантов костылей можно придумать много (идей как всегда есть, а вот сработают ли - ХЗ) ... давайте подождем что скажут гуру из битела

Да - вариант... можно и update пакеты для этих сессий перехватывать... эдак мы скоро свой bgradius_dialup напишем ) не дело это ИМХО.

Вообще функционал вроде не столь сложно реализуем. Для Reject-To-Accept на самом деле тоже сессия поднимается в таблице log_session. Т.е. при авторизации пользователя нужно перед выводом страницы с логином-паролем вызвать некий скрипт, передав ему IP адрес запросившего страницу.
Скрипт лезет в таблицу log_session и получает из списка активных сессий сессию этого адреса и передаёт как результат код договора.
Так же вроде всё?
Только вот скрипт этот не привязан получается к договору, это глобальный скрипт поведения. На глобальное событие. По глобальным скриптам и событиям наработки есть, только в релиз не включены.

Отлично! Можно писать на billing@bitel.ru насчет разработки?

Пишите. Только быстрых сроков не обещаю, надо изучить эти глобальные скрипты, насколько тяжело их вытащить в релиз..