I have a Wi-Fi router within which a Web page is hosted. When I go to Settings in iPhone and select the this particular Wi-Fi network, this web page is popped up (the web page present within the Wi-Fi router). I found that this phenomenon is called Captive portal.
Please suggest me a way to bypass this Authentication process using this Webpage. And do it from with in the Wi-Fi screen of the Settings app. Do I need to make any changes to the Webpage hosted within the Wi-Fi router.
In the Wi-Fi router you might try to "whitelist" your device by IP (DHCP reservation) or by MAC address, to not include the captive portal restriction.
You might try modifying the webpage to recognize your device IP or MAC, and proceed to whatever marks the device "authorized" on the network (usually done by clicking Agree or entering a passcode on the webpage, whatever everyone else presented with the captive portal page is required to do)
iPhone/iPad specifically requires access to apple.com/library/test/success.html to "test" if the device is behind a captive portal or not, if it can't reach that page, with the expected content, then it must be behind the captive portal and therefore show the webpage right after associating to the wireless. Other devices use their own URL, Windows Phones/laptops will use msftncsi.com for example.
Some Apple device users have reported their device thinks it's trapped behind a captive portal, even though the network does not implement a captive portal - this is because Apple has many problems keeping their own URL up. There are have also been many "bugs" in their captive portal detection since iOS6, see: https://discussions.apple.com/thread/4317971?start=0&tstart=0
Related
I'm creating this landing page that's supposed to be triggered by a captive portal.
on my landing page, there's a button to trigger open a <video> element which is then used to scan the QR code.
By default, upon accessing the webcam or device's camera the browser would ask the user's permission first. So basically everything is working fine and all on the browser.
Upon lodging it as a landing page triggered by the captive portal, some inconsistencies arose.
On most Android phones my colleagues have, they simply deny the permission by default.
On some android devices, the popup message asking for permission is shown, and working as expected just like the browser version.
On IOS devices, the popup simply gets blocked (not denied, but ignored)
I know it is ignored on IOS because the error message is not even showing, as if no action is given to the popup by the captive portal.
I've read several forums on captive portals, all led me to believe that captive portals by nature are simply a lighter version of a built-in browser that simply doesn't have the capacity to run window.alert() and window.confirm() nor the ability to keep cookies.
My "research" also led me to believe that captive portals have different sets of behavior unique to the OS, not the browser installed on that OS per se.
1 blog I read today, specifically the comment section, mentioned that from IOS 11.2 on, captive portals should already be able to run window.alert() and window.confirm(). However, upon testing it, this simply isn't the case.
So my question is, is there any way to work around this limitation, by still allowing users to decide whether to allow or deny camera access?
My "research" shows that it is impossible to redirect a captive portal to open on a browser programmatically and only a handful of phones have a captive portal that comes with the "open in browser" option.
Does anyone know any way to, say, intercept the permission popup in action and display it as just a normal HTML element then pass back the user response programmatically?
Thanks in advance! :)
Interfering with system UI flows is not possible. Running code tied to system UI must me tightly controlled to not allow user extorting schemes, like 'Do this with your phone to gain internet access'. Captive Portals from an OS vendor perspective are only about consenting or rejecting the terms of internet use through a provider.
You must change to a two-tiered approach, serving a captive portal and a landing page separately:
Let users check the captive portal
Serve your landing page when they use the browser.
To facilitate and prepare users for the 2nd tier, include a link to your landing page in your captive portal, saying something like 'Start using internet here'. Also have a look at the latest changes in Android and Apple's OSs with regard to Captive Portal API and Captive-Portal Identification in DHCP / RA. (via)
Think of the constrained captive portal as device side aspect, the rich UI landing page as a provider side aspect of accessing internet that can't be united for security reasons.
Trying to write a chrome extension using the chrome.history api. I'm seeing the history reported by chrome.history doesn't contain links visited on other devices (although those links do appear in the chrome://history page on the same device).
Is there an alternative to chrome.history I could use? Is there something else than an extension I could build that could access the full cross device history?
Or is there a reason for the discrepancy between chrome://history and chrome.history?
My end goal would be to highlight links that have been visited cross devices on current pages.
Thanks for any help!
You can check out this answer on Super User which
Reset Sync by going to the Google Dashboard.
Log out of Chrome on all your devices (PC, Mac, smartphone, etc)
Quit Chrome (kill Chrome process if necessary)
Run Chrome again and you should be asked to sign in to your account.
Once all accounts are signed in, the history should sync across all devices
This will re-sync all your devices.
By the way, extensions usually are synced to all devices if users enable the feature, and this means that your app will still show the visited links since it will have access to the device it's installed on's history.
As for the synced data, not event the Chrome browser itself can highlight the data as visited. Google.com usually highlights visited sites, but I just checked my history and the sites I visited on other sites aren't showing.
To solve your issue, you can have users create Premium accounts that gives them access to cross browser link marking. This of course has to be implemented by you.
So the simple idea is that we have a RADIUS server setup to allow users to authenticate with our Ruckus controller via user credentials. On authentication the user should be redirected to a page that allows them to manage MAC authenticated devices.
On everything we have tested so far, including "older" Android devices this seems to be no issue and things run as they should. However with Lollipop (5.0+) versions of Android the captive portal has changed quite a bit, and part of that change is to automatically close the captive portal that launches when you join the network. Because we want them to be redirected to a MAC device management page after authentication so they can add the device they currently logged in with and avoid having to log in again, this is bad.
What I have tried:
Detecting if the browser is being launched in a mobile device and popping an alert in onbeforeunload that attempts to keep the browser open.
Opening a new browser window, pointing to the redirection URL, when successful authentication is detected (essentially managing the redirect ourselves).
Performing Option 2, and then Option 1 on the redirected URL
What won't work:
Asking users to disable the captive portal option on their device. Not trying to point general users to advanced controls.
Creating an open network to access the MAC manager, it must be behind some authentication.
Solution For Now:
We are unhappy with this solution, but for now we are simply asking users to authenticate with the network and then open their browser and go to the basic login portal page (non-network authentication) that users use to manually add devices they can't connect with (like printers, gaming devices, etc.). Though this works, it is a pain for users to have to login, open a browser, manually enter a url, and login again.
This isn't a problem that people haven't run into, see here, I just haven't been able to find a solution from anyone that has run into the problem. Certainly there is some way of utilizing javascript or something to keep the browser open in this situation. If not, anyone have any better ideas for managing things?
We have managed to keep the UAM Browser / captive portal browser open on lollipop by adding firewall rules blocking :
clients3.google.com
clients1.google.com ,
android.clients.google.com
connectivitycheck.android.com
connectivitycheck.gstatic.com
Thus after the user is authenticated the UAM / Captive Browser stays open.
You can keep UAM open as long as you need, you can close it by invoking a reverse proxied 204 redirect to google's connectivity page.
This appears to be new Captive Portal behavior in Android devices since the release of Lollipop (5.0).
We have not yet discovered a workaround. If there is an explicit way to disable the auto-dismissal it is probably only documented in the Android codebase available here (I've been looking, but haven't found anything definitive yet):
https://android.googlesource.com/platform/frameworks/base
FYI, we've also noticed Android uses CloudFront CDN for its captive network detection. Our captive portal solution originally used CloudFront for assets, so we had to whitelist CloudFront subnets in pre-auth ACLs. Whitelisting CloudFront subsequently caused captive network detection to fail on recent Android devices. We had to abandon CloudFront CDN to restore captive portal functionality for Android devices.
Why don't you just hold captive portal opened after authentication? You can always allow access to every site except captive checking sites.
Tested and working both Android and iOS in all versions.
If you need to access cookies/shared storage from default browser (not captive ios/android sandboxed browser), you gotta hop out it before authentication.
On an iPhone device, on an HTML page you can always compose an sms (via an sms:1234567890 URL), and if WhatsApp is installed, you can compose a WhatsApp message (via the WhatsApp protocol).
Is it possible to detect such features on an HTML page?
Following a few hours of research + consulting with top experts I came to the conclusion that there is no legitimate way of achieving the goal of detecting whether a specific app is installed on the device without having the browser re-direct to the app if it is installed.
In iOS for example, there was an app just removed from the App Store because of violating the rules: SysSecInfo. The app managed to pull list of all running processes for example.
From: https://www.sektioneins.de/en/blog/16-05-09-system-and-security-info.html
See https://developer.apple.com/videos/play/wwdc2015/703/ "App
Detection" starting at 08:34
During this talk they discuss several APIs used to gather information
about processes currently running on your system (around 12:12 in the
video) and claimed to have fixed them. However as so often Apple has
only partially fixed the problems they claim to have fixed. Therefore
they have actually never stopped malicious applications from gathering
information about what other applications run currently on your
device, but only removed access to detail information that is only
relevant for harmless system information tools anyway.
System and Security Info is therefore still able to show the list of
running processes and enriches this list with information from the
codesigning information including the list of entitlements running
processes have.
I want to create a Google Sites script that can detect whether my visitors are using Android or iOS and then redirect them to AppStore or Google Play accordingly.
This will allow me to advertise only one QR code for all devices.
Is there a way to easily set it up and host it on Google Sites?
Well the script needs to inspect the HTTP_USER_AGENT header, and do something like this:
Common link to open iOS, Android and BlackBerry app
Bear in mind that not everyone on an Android-based device has the Google Play store (e.g. Kindle Fire -> Amazon Appstore); unfortunately getting the user to an appropriate app store on Android is tricky because there are many options.