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.
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.
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
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.
I have been implementing PayPal Digital Goods Express Checkout in my (HTML5) web app to enable the 'in-app' purchase of extra app content. In my desktop browsers (Chrome, Safari, Firefox) the digital goods flow works without problems. In that flow popup windows are opened at some points, for instance when the user clicks the login button or the button to pay with his creditcard (i.e. without having a paypal account). The popups are no problem for the desktop browsers. However, in Mobile Safari on my iPad 2 popup windows are always opened as (new) tabs, even if a property string containing width, height, etc. is passed to a JavaScript window.open() command. This makes it impossible to implement PayPal Digital Goods Express Checkout and have a good user experience in both desktop browsers and Mobile Safari. When the web app is run full-screen on the iPad (using an icon on the home screen) opening the popups becomes even more problematic (or impossible).
In trying to solve my problem I came up with the following options, none of which has yet led to satisfying results:
Customize the payment flow. Of course this is possible to some point, but after having redirected the user to the 'incontext' Express Checkout page that forces the user to login to PayPal, customization is out of my hands (as far as I know). For instance, I cannot customize the login process itself and make it work in an iframe (instead of a popup window) instead. It would be cool if there were some advanced API commands that I could use server-side to make the user login to PayPal myself, using my own (iframed) login form, but this seems too far-fetched.
Make popup windows work like expected in Mobile Safari, preferably also when a web app is run full-screen. I don't think it strange that Mobile Safari opens new windows as tabs (there are other browsers that do this). I do think it is strange that popup windows that are opened from JavaScript, using window.open and a property string that defines the window's position and dimensions, are opened as tabs. Does anyone know how to make Mobile Safari open such popup windows normally without requiring the users to change some browser setting?
To demonstrate my problem (and show that I am not the only one facing it, though this site's owner probably doesn't know it ;-), go to digitalmagazine.autosport.com with your iPad and click the 'Pay with PayPal' button at the top-left of the page. Click the login button in the PayPal iframe. The site disappears and the login page (that is supposed to be opened in a popup window for an 'in-app' experience) opens full page.
I have also looked at the client side (JavaScript) techniques that are used by similar in-app payment systems, but those (understandably) also use popup windows. Therefore I would prefer the second solution that I have described above. That one will also involve much less work.
While PayPal supports the mobile platform, you will need to make some changes to fully implement it for iOS and other mobile operating systems. You will find the PayPal Mobile overview here: https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_ECOnMobileDevices
The process starts with changing the redirect command in Express Checkout flow to _expresscheckout-mobile, and then steps through a list of additional requirements for full implementation. Read the documentation carefully, as it can be a bit picky when it comes to supported NVP fields.