Проблемы с captive portal Unifi и iOS 7

Проблемы с captive portal Unifi и iOS 7, UniFi Network

jenssegers

Guest

20.09.2013 08:23:00

У меня есть собственный сервер captive portal, который перенаправляет пользователей на страницу в Facebook, когда они нажимают кнопку после подключения. Перенаправление раньше работало на iOS 6 и до сих пор работает на моём ноутбуке, но если подключаться через iOS 7, появляется белая страница с надписью, что загружается Facebook. Я вижу, что вызов authorize API прошёл успешно, потому что кнопка в правом верхнем углу меняется на «готово». Это значит, что пользователь действительно подключён к интернету, но страница не загружается.

Может ли эта проблема быть связана с Unifi?

UBNT-DavidQ Guest	#2 26.01.2015 19:46:00 @UBNT-Anta @UBNT-Tai

jenssegers Guest	#3 25.08.2014 13:02:00 Это всё ещё проблема, лучшее, что можно сделать — снова написать в поддержку Facebook https://developers.facebook.com/bugs/241563039327966.

tsbv Guest	#4 25.08.2014 12:47:00 Есть ли у вас обновления или проблема всё ещё осталась?

Stijn

Guest

08.05.2014 07:34:00

Джим, понятно, и ты прав, но я не контролирую сеть своих клиентов 🙁 поэтому я попытался написать прозрачный прокси на PHP-странице, который работает с HTTP, но не с HTTPS. Так что, похоже, я застрял, пока Facebook не решит исправить эту ошибку...

JimMurray

Guest

04.05.2014 09:32:00

Согласен, это проблема Facebook/Apple, и, судя по тому, что я читал, это её не решит — я не пользуюсь устройствами Apple, и нам ещё никто не жаловался на неё, так что я не тестировал. Теперь, когда я в курсе, проверю в понедельник на работе, прежде чем добавлять в свой бесконечный список задач по исправлению 😉

Вопрос, на который я отвечал (как разрешить сайту с множеством случайных IP-примеров проходить через captive portal), остаётся актуальным в самых разных ситуациях: от PayPal до предоставления «бесплатного» доступа к некоторым сайтам без аутентификации.

Jim

JimMurray

Guest

07.05.2014 23:11:00

Я не совсем понимаю, как у вас всё устроено, но я имел в виду следующее: Гость -> Прозрачный прокси -> WAN. Прозрачный прокси переписывает строку User-Agent, так что весь трафик от гостя с проблемным user-agent автоматически заменяется на такой, который не вызывает баг. Минус в том, что для этого нужен полный контроль над сетью и подходящее оборудование для работы прозрачного прокси (для небольшой сети сойдёт старый ПК). Надеюсь, поможет, Джим. (Сегодня в офисе быстро проверил эту теорию – вроде работает. Не стал углубляться, так как у наших пользователей этой проблемы пока нет, возможно, там ещё какие-то факторы, о которых я не знаю).

Stijn

Guest

07.05.2014 19:56:00

Jim, я пробовал сделать так, но без удачи. Переписывание агента работает на одной странице, если загрузить её на сервере, но когда пользователь нажимает вход, снова происходит запрос на стороне клиента, в результате чего появляется новая пустая белая страница... Я создал баг в FB по этому поводу, но боюсь, что это займет вечность...

JimMurray

Guest

04.05.2014 10:17:00

К сожалению, ваш единственный вариант — ждать, пока Apple или Facebook исправят это, или попытаться прозрачно переписать строку user-agent. В iOS портал с ограниченным доступом всегда использует 'CaptiveNetworkSupport' в качестве UA — если вы замените её на стандартную Webkit-строку для всех запросов, идущих на Facebook, то сможете избежать срабатывания ошибки на стороне Facebook. iOS этого никогда не заметит... Удачи! Джим

Stijn Guest	#10 04.05.2014 10:07:00 Привет, Джим, да, всё правильно. Это гарантирует, что captive portal не сработает, но в нашем случае это не решение. Нам действительно нужно, чтобы captive portal работал так, как задумано 🙁

JimMurray

Guest

#11

04.05.2014 10:03:00

После небольшого дополнительного изучения выяснилось, что разрешение трафика к captive.apple.com и ещё одному URL — именно то, что Cisco сделала, чтобы обойти эту проблему. По всей видимости, если iУстройство видит эти домены, помощник портала захвата никогда не запускается, и устройство может авторизоваться через браузер обычным способом. Это не исправляет сломанный помощник портала, но даёт вполне приличное решение, которое позволяет клиентам подключаться.

Если уж на то пошло, и у вас полный контроль над сетью вне вашего хотспота, а также есть время, желание и возможность настроить прозрачный прокси, вы, вероятно, сможете переписать строку user agent в запросе к facebook так, чтобы она не отправлялась как «CaptiveNetworkSupport», а как стандартный Webkit UA — это должно эффективно обойти проблему и сохранить работу портала захвата iOS. Но это довольно большая работа и не всегда применимо.

Джим

Stijn

Guest

#12

04.05.2014 09:16:00

Джимин, эта настройка не поможет. Если разрешить трафику проходить к captive... тогда всплывающее окно вообще перестанет появляться для captive портала. «Ошибка» в apple captive portal проявляется пустой страницей (например, при входе через Facebook, как описано в этом баг-репорте). Значит, разработчикам контроллера или Facebook нужно исправить эту ошибку, чтобы снова можно было использовать iPhone 5/5C/5S и некоторые iPad.

JimMurray

Guest

#13

04.05.2014 09:03:00

Решение — добавить разрешённую подсеть для ios captive, но проблема в том, что IP-адреса рандомные. Есть ли способ разрешить доменное имя?

Если у вас есть доступ к DNS-серверу на вашем хотспоте, просто настройте его так, чтобы «проблемные» домены резолвились в один и тот же IP. Добавьте этот IP в список разрешённых на контроллере — и всё.

Пример: сейчас captive.apple.com резолвится в 23.74.87.91. Я настроил бы свой DNS-сервер так, чтобы captive.apple.com всегда вел на этот адрес (вместо обращения к Apple). Тогда мои клиенты всегда будут видеть captive.apple.com с IP 23.74.87.91, который я могу добавить в список разрешённых на контроллере.

Надеюсь, поможет. Джим

(Apple действительно нужно гораздо тщательнее тестировать свои продукты. Половину своего времени сейчас я трачу на решение проблем с Apple iDevice!)

Stijn

Guest

#14

04.05.2014 08:40:00

Думаю, есть два способа решить проблему, но насчёт второго не уверен:
- Facebook исправит баг
- Обновить хотспот

Мне кажется, что Cisco и O2 смогли решить это через обновление ПО... но я нигде не нашёл, что именно они сделали.

Я тестировал на 4 устройствах:
- iPad 2/iOS 7: работает идеально
- iPhone 4/iOS 7: работает идеально
- iPad Air/iOS 7: не работает
- iPhone 5/iOS 7: не работает

Кто-нибудь ещё что-то знает?

jenssegers Guest	#15 16.04.2014 10:33:00 У меня эта проблема всё ещё есть, и, похоже, Facebook всё ещё «работает» над её устранением: https://developers.facebook.com/bugs/241563039327966

AnkBurov Guest	#16 15.04.2014 22:08:00 Напоминаю.

andreasanta

Guest

#17

13.02.2014 09:27:00

Да, было бы здорово, если бы captive portal от Unifi поддерживал передачу доменного имени или специальную передачу при совпадении HTTP-заголовков с определённым регулярным выражением, ведь iOS 7 использует особый user-agent при отправке запроса на captive portal. Ubnt, есть ли шанс добавить это в ближайшее время? Для нас это становится действительно срочно...

etza

Guest

#18

05.02.2014 08:17:00

Решение — добавить разрешённую подсеть для iOS captive, но проблема в том, что IP адреса случайные. Есть ли возможность разрешить по доменному имени? http://stackoverflow.com/questions/19055502/facebook-com-and-the-ios7-captive-portal-detection Я тестировал с IP — работает!!!!!
www.appleiphonecell.com
captive.apple.com
captive.apple.com
www.apple.com
www.itools.info
www.ibook.info
www.airport.us
www.thinkdifferent.us

marcromera

Guest

#19

04.02.2014 09:44:00

Я пробовал добавить этот параметр в URL для входа через Facebook, который предоставляет PHP-SDK (так как я использую вход через Facebook в captive portal), и в этом случае это не работает. Я не проверял переход на страницу Facebook, так как мне это не нужно.

PeterTarget Guest	#20 03.02.2014 16:15:00 У меня проблема с подключением к любому captive portal на iPhone, так что я не уверен, что это связано с Unifi.

Читают тему (гостей: 1)