BiTel

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

Есть такая задача: сделать в домашнем кабинете возможность просматривать графики использования канала, параметры качества линии и т.д.
Все эти данные собираются отдельным сервером статистики непосредственно с dslam'ов и хранятся в rrd. Есть отдельная табличка соответствия портов пользователям.
Просто вставить в кабинет <img src="http://statistics.provider.net/dslam1/port100.png"> для соответствующего пользователя я не могу - не хочется светить порты и предоставлять возможность всем смотреть все графики... нужно как-то осуществить авторизацию на втором сервере связанную с авторизацией в домашнем кабинете...
Какие есть мысли: у меня есть cgi скриптик на сервере статистики, которому можно передать набор параметров, в соответствии с которым он и показывает картинку. Можно передавать какой-то уникальный ID текущей сессии (имеется ввиду авторизация пользователем в домашнем кабинете), а уже скриптик проверит, есть ли такая сессия и если есть - то какой ей соответствует контракт, и т.д. Теперь уже для просмотра чужих графиков придется перебирать длиннющие наборы цифр и даже если подобрать - то максимум можно увидеть просто картинку, без какой-либо информации о владельце или номере порта...
Вопрос - есть ли такая сессия и где ее искать в базе и как ее получить в xslt для передачи в качестве параметров в <img>?
Или есть еще какие-нибудь варианты?

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

а как скриптик должен проверить какой контракт соответствует этому вот уникальному ид?

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

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

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

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

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

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

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

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

насчет логина и пароля - тоже можно, если подскажете как их в xslt получить. Получить логин как описано на wiki у меня не получилось:
viewtopic.php?f=19&t=1342&start=15

почему-то
Subject subject = Subject.getSubject( AccessController.getContext() );
дает null.

Да, но поймите... теоретически можно вытащить из реквеста в нашем сервере куки, в экшене их засунуть в xml и тем самым "получить их в xslt". И вы можете передать его, стало быть к себе наа сервер в генератор картинки. Но ни в какой базе кук этих нет, конечно, они в самом сервере внутри где-то, потому вы никак не сопоставите издалека эти куки с конкретным догоовром. По крайней мере, я не представляю как это сделать. Разве что запросить страницу и распарсить оттуда номер договора. Или как у вас внутри вашего скрипта сопоставляются ваши графики? С договорами, с пользователями или как?

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

а... ну тогда - да, если в базе их нет, то этот путь никуда не ведет...

значит, буду передавать скрипту логин/пароль. Помогите с этим, пожалуйста. Я описал проблему здесь:
viewtopic.php?f=19&t=1342&start=15

Очень интересная вещь, как успехи с ее реализацией

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

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

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Реализовал теперь при просмотре статистики по трафику - внизу рисуется график загрузки пользовательского канала за выбранный период. Еще переделал ненужный action на страничку где показываю пользователю графики его SNR, attenuation и скорости подключения модема.

Спасибо всем, кто помогал с вопросами!

mrtg/rrd рисует по файлу своего формата или по rrd базе. Тут хорошо бы другое решение:
viewtopic.php?f=5&t=2219
если вас тоже интересует- проголосуйте за
мне бы такая фишка тоже пригодилась, так как не со всех dslam'ов я могу снимать данные по snmp, а в netflow данные по трафику и времени уже есть, было бы просто здорово помимо скучных цифр увидеть красивый график с разбивкой по типам трафика

э-э-э ... при чем тут SNMP? skyb предложил почти рабочее решение .. почему почти? потому что "время сессии деленное на кол-во полученных данных равно скорость" это какбы не айс, на мой взгляд кошерное рисование графиков выглядит так:
1 вариант - раз в 5 минут (чаще думаю нет сысла) лезем в БД и берем данные по всем онлайн юзерам, перебираем их в цикле в котором смотрим кол-во принятых/переданных байт и отдаем эту инфу на съедение MRTG (надеюсь как в MRTG использовать скрипты объяснять не надо?) - он Вам по каждому юзеру нарисует дневные, недельные, месячные и годовые графики
2 вариант - опять раз в 5 минут лезем в БД с сессиями, берем оттуда онлайн юзеров и ... и смотрим циферки их наработки по услугами - вот вам и исходные данные для рисования графиков по локальному/интернет трафику

можно вообще не использовать MRTG, а напрямую писать в rrd базу или даже писать эти данные в отдельную БД - тут как Вам удобно, главное чтоб было откуда вытащить данные для того чтоб график нарисовать ...

snark... нет слов....

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

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

Я его променял на платное решение, потому как запарился с его разработкой, а тут - команда разработчиков, постоянное развитие, форум... я готов оплачивать нужные мне доработки, с пониманием отношусь когда мне разработчики говорят - не... это ломает структуру биллинга - мы этого делать не будем.
С вами же какая-то каша из топора получается... Да, я все что мне надо, САМ могу сделать, но тогда мне на этом форуме и среди пользователей этого биллинга делать нечего...

ну народ ... молчишь в тряпочку - плохо! предлагаешь в общем то рабочее решение - тоже плохо! поймите, я не против того чтобы БГБ развивался, но если решение нужно здесь и сейчас то проще сделать то что надо самому, чем ждать пока дойдет очередь вашей хотелки в TODO разработчиков, если она (хотелка) туда вообще попадет ... если Вам это критически важно и очень-очень нужно - пишите ТЗ и заказывайте доработку, а если это не к спеху и Вы готовы подождать пока это реализуют то можно и самостоятельно выкрутится

в ссылке которая указывает на апрельский пост написано что данные в БД есть
так кто мешает нарисовать график в XSLT без всяких там ррд и тп ? я чего то не понимаю
в "ядро системы" никто такое совать не будет, есть пользователи БГБ (не будем показывать пальцем) у которых за месяц по ляму dial-vpn сессий если не больше
а в своем вебе каждый себе сам злобный буратина, хоть 3D диаграму рисуйте

Впринципе да, но прикрутить можно, а вот если это все реализовать штатными средствами было бы супер.
Я проголосовал viewtopic.php?f=5&t=2219

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

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

скриншоты выложил здесь:
viewtopic.php?f=5&t=2219

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

так ведь никто и не мешает, просто всем хочется "изкаропки"


не Вы один

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

С таким подходом долго еще за бугор будут уходить вагоны с нефтью, а обратно - цветные бусы...

биллинг - штука очень индивидуальная и каждому, кроме сертифицированного расчета 2*2=4, в нем надо что-то свое, а БГБ - тот вообще, IMHO, под Уфанет писался и пишется, отсюда и его функционал - функционал необходимый Уфанету + функционал доработанный за $ + функционал который выклянчило комьюнити, так что - либо реализуйте сами, либо долго и нудно доказывайте что это важно и нужно в надежде что ваша хотелка появится в TODO, либо пишите ТЗ и платите за доработку под:

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

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

мы с Вами довольно давно общаемся, но, ЕМНИМС, еще ни разу не спорили и я не собираюсь этого делать

не надо путать мягкое с теплым

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

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

вообщем я к тому что вы и правы и не правы одновременно, есть ситуации когда надо выбирать между "шашечки или ехать", хотите биллинг за 100к деревянных, с мегафункционалом, с API для скриптования бизнесс логики, да еще и шашечки ? а изоленты хватит ?

snark, согласен по всем пунктам последнего поста

только вот bgbilling я воспринимаю как нечто большее чем уфанетовский биллинг, уж больно я доволен своим небольшим (полугодичным) опытом общения с ним. Да и - посмотрите карту биллинга! Надо продолжать двигать вперед:

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

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

Но это выходит за рамки данной темы. Кабинет я со статистикой интегрировал. Всем спасибо

Jimson, ну знаю, знаю... верно говорите (особенно про бутерброд)
но поймите, надо ж знать золотую середину, неужели красивая картика которую разработчики забацают за пару дней и которая украсит ЛИЦО биллинга - его домашний кабинет будет стоить 100 кило баксов...

Домашний кабинет будет в версии 5.1-5.2, тут идут работы в наших лабораториях, пока неизвестно чем закончится.

По поводу utf-8 тут больной вопрос, кто-то из нас сильно хочет utf-8, а кто-то говорит нафиг надо. И это справедливо, потому что наверняка будут проблемы с кракозябрами, а разбираться с этим мало кому хочется. Вам хочется иметь возможные проблемы (временно, конечно)?

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

можете обрисовать, хотя бы в общих чертах, чем "домашний кабинет" будет отличаться от текущего положения дел


многовалютность - это да, это было бы неплохо, ну а особой важности UTF именно для биллинга лично я особо не вижу

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

Про многовалютность - из той же песни.