- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Splash Page redirect limited to "GET HTTP 80" detection
Hello there, I am reading up for the ECMS Certification.
The linked article https://documentation.meraki.com/MR/MR_Splash_Page/Splash_Page_Details_for_Meraki_MR has the following note after describing the considerations of the click through splash page.
Note: The AP looks for HTTP GET requests on TCP port 80 in order to redirect users to the Splash page. If Block all access until sign-on is complete is enabled for the Captive Portal Strength, and the user attempts to access a web page that uses HTTPS, the AP will be unable to redirect the browser to the Splash page because the web traffic is encrypted. Additionally, if the user attempts the access a web page that uses a different port other than TCP port 80 the connection will also be blocked. In either case, the user's browser will timeout. If this is occurring, verify users are accessing a web page using HTTP over TCP port 80.
I wanted to ask if the limitation of only detecting a HTTP request on port 80 is still the case. Is it really not possible to redirect HTTPS requests to the splash page? Article is listed as being updated on Aug 7th 2024.
Solved! Go to solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is usually not an issue these days because pretty much every platform has a built-in test to retrieve a special URL to determine whether it is behind a guest portal.
For example, Windows uses:
http://www.msftconnecttest.com/connecttest.txt
Apple uses:
http://captive.apple.com
There are also mechanisms like the "venue-info-url" that a device can use to get info about the captive portal it is attached to.
https://developer.android.com/about/versions/11/features/captive-portal
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately it is indeed still the case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is due to how HTTPS works. Most modern browsers and OS have captive portal detection that should mitigate the issue in most cases.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is usually not an issue these days because pretty much every platform has a built-in test to retrieve a special URL to determine whether it is behind a guest portal.
For example, Windows uses:
http://www.msftconnecttest.com/connecttest.txt
Apple uses:
http://captive.apple.com
There are also mechanisms like the "venue-info-url" that a device can use to get info about the captive portal it is attached to.
https://developer.android.com/about/versions/11/features/captive-portal
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you to every one that took time to reply, very much appreciated. I learnt something that I would not have understood otherwise.
Marking @PhilipDAth as the solution purely because anyone else reading this thread in the future will benefit from the links.
