Гибкость в управлении external captive portal

one0fnine

Не хватает управлением опций через параметры, которые отправляем на точку/2.2.2.2:

- временем сессии

- редирект ссылкой

Идеально было бы:

Возможность выбора предустановленных параметров для external captive portal. Например, как сделано у Aruba InstantOn. Есть список партнеров, при выборе нужного, подставляются сразу все параметры. Партнеров они добавляют по письму в поддержку.

onatoli4

Добрый день!

Какой сервис авторизации вы используете? 
Можете показать пример выбора предустановленных параметров в InstantOn? 

Я правильно понимаю, что нужна поддержка атрибутов Radius - Session timeout? Для редиректа ссылкой какой атрибут требуется?

Эти параметры, в целом, можно указать в настройках Nebula.

one0fnine

onatoli4 написал:

Добрый день!

Какой сервис авторизации вы используете? 
Можете показать пример выбора предустановленных параметров в InstantOn? 

Я правильно понимаю, что нужна поддержка атрибутов Radius - Session timeout? Для редиректа ссылкой какой атрибут требуется?

Эти параметры, в целом, можно указать в настройках Nebula.

Мы пишем свой. www.smartwifi.ae

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

Но там на самом деле все просто. Выбираем партнера, подставляются все настройки для работы с внешним порталом.

Аттрибуты... С радиусом чуть ниже. Смотрите, у большинства брендов мы можем отослать параметр времени сессии и редиректа в запросе к точке/контроллеру.

Например, для Aruba IAP или InstantOn формат GET запроса такой: 

"https://%{target}/cgi-bin/login?%{query}"

где query содержит параметр session_timeout и url

TPLink с контроллером Omada POST запрос:

%{scheme}://%{target}:%{targetPort}/portal/radius/auth

в теле запроса содержаться: originUrl, время сессии не управляется через параметры.

на самом деле здесь нет необходимости в originUrl, чуть ниже опишу почему.

у EnGenius также через GET запрос содержит параметр userurl, время сессии не управляется.

У Cisco Meraki есть в POST запросе на контроллер success_url и duration

у OpenMesh через GET запрос:

http://%{uamip}:%{uamport}/logon?%{query}

в query содержится redir параметр, сессия не управляется.

Есть еще один момент. Везде где есть облачный контроллер (TPLink, Cisco Meraki) запрос на него уходит через POST, независимо откуда происходит запрос, от клиента или от внешнего сервера. В теле запроса есть параметры, которые отвечают за авторизацию клиента на точке.

Где GET запрос это точки в Standalone, кроме Aruba. Там точка перехватывает запрос и авторизирует клиента по параметрам.

В конфигурации с Nebula же есть, некоторая сложность. Судя по шаблонам, мы должны отправить username и password через POST(GET) запрос на 2.2.2.2 от клиента. Насколько я понял, точка перехватит запрос и авторизирует его. Но в целом - это логика точек в standalone режиме. Не на всех гаджетах мы сможем сделать POST запрос через AJAX, к сожалению, все еще некоторые это не поддерживают. Почему AJAX? Потому что вначале данные уйдут на сервер портала из заполненной формы, а потом передадутся для авторизации на точку/контроллер.

Единственный рабочий вариант на всех устройствах - это GET запрос (для нас, вероятно, и не только). Тогда мы не можем управлять динамически redirect url. Как дополнительный кейс, здесь еще важно учесть, что есть организации, которые хотят чтобы ссылка была на каждой точке разная. Хоть и точка установлены все в одной локации.

По итогу, здесь простое решение - это ссылка для редиректа через параметры, как сделано у большинства брендов. Либо правильное решение - это сделать полноценное API для Nebula. Иначе сейчас выглядит так, что точка авторизирует как standalone, но работает через облачный контроллер.

По RADIUS. Да, аттрибут для сессии нужен. На самом деле я думал, что он используется. Как и вот эти:

WISPr-Bandwidth-Max-Up
WISPr-Bandwidth-Max-Down

Но мои тесты показали, что скорость не режется. Видимо сессия тоже

redirect url не должен быть в RADIUS. Он не предназначен для этого. Лучше исходить из такой логики. Если redirect url указан в настройке captive portal, то переходим туда всегда. Если он не указан, и пришел параметр в запросе от клиента, то перейти по ссылке в параметре.

one0fnine

@onatoli4 Добрый день.

Написал целый опус, опубликовал, его нет. На форуме ревью постов есть?

onatoli4

Опус вернули 

Спасибо за подробное описание, я переговорю с разработчиками и позже дам ответ.

onatoli4

Добрый день

Разработчики ответили, что время сессии (session timeout) поддерживается.
Redirect url и ограничение скорости можно задать в настройках Nebula, поэтому в ближайшее время добавлять их для поддержки в external captive portal не планируют. Они рассмотрят этот вопрос в 2022 году, как и выбор предустановленных параметров. 
На этот год роадмап уже расписан.

one0fnine

onatoli4 написал:

Добрый день

Разработчики ответили, что время сессии (session timeout) поддерживается.
Redirect url и ограничение скорости можно задать в настройках Nebula, поэтому в ближайшее время добавлять их для поддержки в external captive portal не планируют. Они рассмотрят этот вопрос в 2022 году, как и выбор предустановленных параметров. 
На этот год роадмап уже расписан.

а можно узнать, какой параметр в запросе отвечает за время сессии?

redirect url задать можно, но управлять им из параметров нельзя. а это одна из основных вещей, что предлагают компании, которые разрабатывают свое решение для captive portal.

в любом случае спасибо за фидбэк