So, I'm building a Guest Internet portal for a public hotspot in a hotel. This means the portal is served through a Network Access Gateway (a Nomadix) that redirects all outgoing traffic to the portal page. The portal needs to be able to set cookies on the browser so that Guests can be automatically logged back in after they idle timeout.
The Problem:
iOS4+ and OS X (10.7+) Devices have a feature called Captive Network Support. This feature continuously scans for Wifi SSIDs, connects to them, and curls http://www.apple.com/library/test/success.html to see if the device is connected to the internet. If it doesn't get the Success response, these devices pop open whats called a Captive Network Portal. This portal is not a true version of Safari Mobile and you cannot save cookies on this browser.
I would like an authoritative answer to the following question:
With client-side javascript/markup can I?
A) Save cookies within the Captive Network (popup) browser
B) Prevent the Captive Network browser from popping up in the first place without whitelisting apple.com
This is kinda the wrong site in the StackExchange network for sysadmin stuff; you may wish to try ServerFault. In my experience as a user, there are WiFi portals out there that manage reauthentication without cookies; perhaps ServerFault can help you find such.
That said, there's one possible solution in terms of iOS client-side development: There are CaptiveNetwork APIs which allow a third-party app to inform the system that it's assumed responsibility for authenticating to particular SSIDs, suppressing the web sheet. It's likely not a desirable solution, since it requires your users to install an app, but it's there.
You could try serving "http://www.apple.com/library/test/success.html" locally when ever an iOS device is detected. This will make the CNA not pop up and then the user could login through mobile safari, in which you can save cookies.
iOS 14 has a new API for work with a captive portal. Btw, Android supports it too
Related
I have been searching for an answer on how to connect to a WiFi hotspot using Javascript in browser.
Context: I'm building a page that show WiFi information such as SSID and Password after scanning a QRCode, and the page shows which Network you're going to connect to before actually connecting for security
I have found this : php-wifi, which seems to be what I want in PHP, but nothing for Wifi interface in Browser Javascript, I've search "wifi" in npmjs but no success.
I'd like it to work on all devices, if possible
Thanks for your help
It would be impossible to scan network on browser due to restricted access by design, but you could do it on Node.JS with this package: https://www.npmjs.com/package/node-wifi.
For browser, only limited network information could be retrieved, check this document: https://wicg.github.io/netinfo/
Can anyone explain me the possibilities of creating a web chat (i.e similar to whatsappweb) which works without internet connections the only possible way that these device communicate is either by WiFi or Bluetooth (i.e Peer to peer). If it is not possible on earth could then explain why?
I've come across some javascript files like peer.js. But it uses internet i think. I want it to work without internet connectivity.
Thanks in advance.
With WebRTC it is possible to establish peer-to-peer communication between web-browsers in the same local network: https://developer.mozilla.org/en-US/docs/Web/Guide/API/WebRTC/Peer-to-peer_communications_with_WebRTC
A server is only needed for communication outside of a local network: http://blog.vline.com/post/63765098884/webrtc-if-its-p2p-why-do-i-need-a-server
There is another demonstration in this page: https://hacks.mozilla.org/2013/05/embedding-webrtc-video-chat-right-into-your-website/
However WebRTC is a relatively new system that is not widely supported - so consider it experimental at this stage - but it has the backing of Mozilla, so it might end-up somewhere.
However you are limited to the capabilities that WebRTC provides - and as your code is still JavaScript that runs in the browser you will not have access to any kind of actual networking API (such as Berkeley Sockets) or lower-level control of hardware, such as the ability to create Ad-hoc Wi-Fi networks, new Bluetooth Personal Area Networks, or LE Bluetooth connections... at present.
Google is working on making a Bluetooth API available that runs in the browser. Presently it is only available to Chrome Extensions, but it may soon be available in web-pages in general: https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web
Ofcourse there is a way to make this happen. You would have to set up a webserver on the device with this webapp. You could then connect with localhost or 127.0.0.1 . Other people would have to join your hotspot and connect to your ip address.
If you want to connect automaticly you would have to write a real app.
Browsers run in a "contained" mode. No hardware access is possible from any script ran inside the browser, thus there's no way to initialize and setup the device to start direct communication.
From previous projects I know that Apple's Captive Network Assistant (aka WISPr client, too) runs a restricted browser, see How can I debug the browser in Captive Portal? and Ajax on Captive Network Assistant on iOS and OSX.
My hotspot is running a angularJS web page. On a Windows Phone 8.1 and an OS X Lion my angular page works fine. On my iOS 8.3 there must be a JavaScript error somewhere in the code, because I can see the angular variable expressions {{myVar}} in the code which means the angular framework isn't loaded properly.
Any idea what could be the cause?
Solved
Cause has been found, not by me but a friend of mine. Turns out that the CNA browser (WISPr client) doesn't allow the use of the browser's local storage. Whenever you try to write some data into the local storage, the application crashes.
Thus, the solution is either to switch from local storage to normal cookies or to do a user agent detection in JavaScript and exclude CNA browser (WISPr clients) from the use of the local storage.
Many thanks #chedabob, the idea of checking if JS is enabled led to the local storage check. Really appreciate your support.
You could possibly use WeinRe to remotely debug it, however if the root of your problem is the Captive Portal view isn't running Javascript, this probably isn't going to help
https://people.apache.org/~pmuellr/weinre-docs/latest/
Perhaps this is a fairly big and ambiguous question:
In the Stack Overflow chatrooms, there is a button to "enable desktop notifications," which will show something in the system tray when someone replies to you.
By what mechanism does this work? It's always made me curious.
How does a website access the system tray?
It uses the Notification object (i.e. var n = new Notification("Hello");) to provide local notifications on a per-website basis. Each browser implements the standard differently (see Chrome, Firefox, and Safari), but they all operate essentially the same way, sending notifications based on the permissions they have (window.Notification.permission), which can be default (hasn't been asked, in which case you would window.Notification.requestPermission();), granted, or denied. Opera and Internet Explorer do not support desktop notifications at this time.
They're called Desktop Notifications, which use the Notifications API.
Basically, the site checks for Notifications API support, then the user grants or denies the website permission to display notifications.
Here is more information on how the API works.
This is with the help of WebSockets - Web APIs. There is actually a persistent connection between the client and the server. And also both parties can start sending data at any time.
I have an ASP.NET application that, among other things, is scraping another web site. I'm using a headless System.Windows.Forms.WebBrowser control in an STA thread, using Navigate(), handling the DocumentCompleted event, yada, yada. The WebBrowser control navigates to the remote site's login page (which uses javascript to fiddle with the DOM, thus the need for WebBrowser). I set the UserID and Password fields then I call WebBrowser.Document.All["submit"].InvokeMethod("click").
On my development box running Windows 7 and IIS 7.5, this behaves as expected. The next time DocumentCompleted fires, it's clear that I've successfully logged in and I go smartly about my business. On my Rackspace production server however, running "Windows Server 2008 Enterprise without Hyper-V" and IIS 7.0, it was failing: On that box, the next time DocumentCompleted fired, I would find that I'd received the remote site's "You've been logged out." page.
I tried adding the remote site to the Trusted Sites list, and disabling IE ESC for Administrators and Users, to no avail.
I finally managed to achieve the desired behavior -- the behavior I'd seen in my development environment -- by running this app in a special application pool whose identity I had set to Administrator. But I don't want to leave it that way.
What is the least privileged identity, or the minimum set of permission(s) sufficient on the application pool to allow this headless STA WebBrowser to properly browse this javascript-dependent remote site?