我可以触发移动客户端在连接 wifi 时自动启动网页浏览器吗？
假设您对无线路由器有完全的编程控制（运行 OpenWrt 或 DD-WRT - linux）。路由器配置为广播 ssid，并且网络是开放的。
一位移动用户（iPhone/Android/BB）走过来。
1) 在 iPhone 上，如果设备当前未连接 WiFi，则会出现一个对话框，提示连接到可用的 SSID。用户选择我的 ssid 并连接。有没有办法从我的路由器（比如使用 Bonjour 或 ??）触发 iPhone 启动网络浏览器并尝试自动加载主页或自动配置 URL？
2）Android/BB 有什么不同的答案吗？
原因是，在“围墙花园”应用程序中，我需要能够弹出一个问候页面，并且不希望用户必须先笨手笨脚地加载默认页面。
任何和所有的想法表示赞赏！ 谢谢 RM。
更新 - 我认为答案可能在于 802.21 或 UMA。我在某处读到 ATT 使用 iPhone 进行身份验证。
在 iPhone 上，当连接到 WiFi 网关时，有一个名为“自动登录”的开关。如果你打开它，iPhone 会发送一个 HTTP 请求，并接收来自我的热点的重定向，然后我发送欢迎页面。 （该地点完全开放）。问题是 iPhone 似乎在等待某些特定的事情 - 它不会从“3G”更改为 WiFi，并且最终可能会超时。此外，它仍然显示停靠在窗口顶部的“登录”横幅。
有人知道我需要发送以进行正确的自动登录的框架的文档吗？
Assume that you have complete programmatic control over a wireless router (running say OpenWrt or DD-WRT - linux). The router is configured to broadcast an ssid, and the network is wide open.
A mobile user (iPhone/Android/BB) walks up.
1) on iPhone, if the device is not currently wifi connected, a dialog appears that offers to connect to available SSIDs. The user picks my ssid and connects. Is there a way, from my router (say using Bonjour or ??) to trigger the iPhone to launch the web browser and try to load the home page, or an autoconfig url automatically?
2) any different answer for Android/BB?
The reason is that in a 'walled garden' application I need to be able to pop up a greeting page and don't want the user to have to fumble around loading a default page first.
Any and all thoughts appreciated!
Thanks
RM.
Update - I think the answer may lie in either 802.21 or UMA. I read somewhere that ATT uses this with iPhones for authentication.
On iPhone there is a switch called 'autologin' when connecting to a wifi gateway. If you turn that on, the iPhone sends an HTTP request, and receives a redirect from my hotspot, and then I send the welcome page. (the spot is totally open). Problem is that iPhone seems to be waiting for something specific - it doesn't change from '3G' to wifi and may eventually time out. Also it still displays the 'Login' banner docked to the top of the window.
Anyone know of documentation for the frames I need to send to do a proper autologin?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
HTTP 302 重定向
最常见的技术是简单地阻止网络上的所有出站流量，然后将任何端口 80 流量重定向到您自己的门户页面（本地或远程托管）。然后，该门户页面将提供“验证”用户的方法（通过在防火墙上戳一个洞）。有一些第 2 层方法，例如 chilispot，它们提供所有相同的功能，并且如果您想要更喜欢的话，可以针对 Radius 服务器进行身份验证。
// 致力于创建一个 wifi 热点，当移动设备连接到 wifi 时，它将自动触发移动浏览器（直接到我商店的链接）。这将成为用户的一个有趣因素，注意到我们的热点的一些特别之处当他们穿越它时..
HTTP 302 Redirect
The most common technique is to simply block all out bound traffic on the network and then redirect any port 80 traffic to your own portal page, either local or remotely hosted. This portal page would then provide the means to "authenticate" the user (by poking a hole in the firewall). There are layer 2 methods such as chillispot which provide all the same functionality and can be authenticated against a radius server if you wanted to get fancy.
// Working on creating a wifi Hotspot, which would automatically trigger mobile browsers(directly to my shop's link) when the mobile device is connected to the wifi.. This would serve as an interesting factor to user's, get noticed something special about our Hotspot when they cross across it..
我认为您正在寻找的是创建标准 wifi“热点”的能力。
网上有一些关于如何执行此操作的非常好的教程，其中一些使用 DD-WRT。
例如，查看以下内容： http://www.hotspotsystem.com/en/hotspot /install_guide.html
其中给出了一些例子。
I think what you're looking for is the ability to create a standard wifi "hotspot".
There are several very good tutorials online about how to do this, several using DD-WRT.
For example, check out this one: http://www.hotspotsystem.com/en/hotspot/install_guide.html
which gives some examples.
您所描述的是一个强制门户系统（热点、围墙花园等）。该功能可以通过 openwrt 上的多个应用程序来实现。查看另一个答案，了解 openwrt 答案 中提供的每个特定选项的详细信息。
有几种常见的技术可以实现强制门户
HTTP 302 重定向
最常见的技术是简单地阻止网络上的所有出站流量，然后将任何端口 80 流量重定向到您自己的门户页面（本地或远程托管）。然后，该门户页面将提供“验证”用户的方法（通过在防火墙上戳一个洞）。有一些第 2 层方法，例如 chilispot，它们提供所有相同的功能，并且如果您想要更喜欢的话，可以针对 Radius 服务器进行身份验证。
DNS 重写
另一种技术是使用 dns 规则重写任何 dns 查询以解析到您自己的网络服务器，然后该服务器将向用户显示登录页面，一旦用户“经过身份验证”，您只需更新其 dns，或允许来自 dns 的请求该用户要传递到上游。
IP 重定向
此技术通常与 HTTP 重定向有一些重叠。本质上，您将他们的请求重定向到新的目标 IP。您可以设置一个鱿鱼代理来处理这些请求。
iOS 和 Android 设备都将通过简单地检查标准 URI 资源来检测强制门户（例如：http://www.apple.com/library/test/success.html），如果该资源被阻止，那么您就处于离线状态，如果该资源被 302 或 307 重定向，那么它假设有一个俘虏门户到位，他们将打开浏览器。如果找到该资源，那么他们会假设您在线并且不会自动打开浏览器。
Android 将在手机或平板电脑上打开标准浏览器以允许用户进行身份验证。然而，iOS 设备将打开一个伪浏览器，这是一个有限的应用程序，不允许诸如视频播放弹出窗口等内容。
我认为 WISPr 协议最初适用于没有网络浏览器的设备接受条款和条件，从而允许这些设备使用通用协议来接受强制门户并进行身份验证。我什至不确定 WISPr 协议是否被真正接受过。 （也许他们重新起草了它）
（抱歉，我不知道这原来有多旧）
What you're describing is a captive portal system (hotspot, walled garden, etc). This functionality can be implemented with several application on openwrt. Check out another answer for details on each specific option offered in openwrt Answer.
There are a few common techniques to implement a captive portal
HTTP 302 Redirect
The most common technique is to simply block all out bound traffic on the network and then redirect any port 80 traffic to your own portal page, either local or remotely hosted. This portal page would then provide the means to "authenticate" the user (by poking a hole in the firewall). There are layer 2 methods such as chillispot which provide all the same functionality and can be authenticated against a radius server if you wanted to get fancy.
DNS Rewrite
Another technique is to use dns rules to rewrite any dns query to resolve to your own webserver which will then present the user with a login page, once the user has "authenticated" you simply updates their dns, or allow the dns request from that user to pass upstream.
IP Redirect
This technique often times overlaps a bit with the HTTP redirect. Essentially you redirect their requests to a new destination IP. You could setup a squid proxy to then handle these requests.
Both iOS and android devices will detect for captive portals by simply checking for a standard URI resource (eg: http://www.apple.com/library/test/success.html) and if that resource is blocked then you're offline, if that resource gets 302 or 307 redirected then it assumes there is a captive portal in place and they will open a browser. If that resource is found then they assume you are online and no browser is auto opened.
Android will open the standard browser on the phone or tablet to allow the user to authenticate. iOS devices will however open a pseudo browser which is a limited application which doesn't allow things like video playback popups etc.
The WISPr protocol I believe was originally intended for devices which do not have a web browser to accept the terms and conditions and thus allowing these devices a generic protocol to accept and authenticate against a captive portal. I'm not even sure that the WISPr protocol was ever really accepted. (perhaps they redrafted it)
(Didn't realize how old this originally was, sorry)
好的，解决了。
该协议称为 WISPr - 现在版本 2.0
一些链接
http://erratasec.blogspot.com/2010/09/apples -secret-wispr-request.html
和跟踪
http://coova.org/node/4346
Ok, solved it.
The protocol is called WISPr - now version 2.0
some links
http://erratasec.blogspot.com/2010/09/apples-secret-wispr-request.html
and traces
http://coova.org/node/4346