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?
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)
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
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..
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.
Related
I have "unverified app screen" when I request access to Google accounts.
To get rid of it I want to fill out OAuth Developer Verification Form. But, I got some problems with that due to some restrictions on my environment.
There is a field:
Homepage URL for your app *
The problem is that in my application my home page is not accessible publicly. Usually, it can only be accessed using VPN connection.
For push notifications, I use different URL that only handles them, but for the UI there is no access from the world without VPN. I was thinking of overcoming the issue and have a few ideas, but I'm not sure whether they will work.
Inform Google of restricted access to the home page via this field:
Is there any other information you can provide that will be useful?
However, this approach might not work due to the fact that it's not said that I can omit to specify the home page.
Find out what addresses google requests homepage from and to allow access to it from those addresses. But, firstly it's insecure and secondly, it's still a question how to get these addresses.
Make some static resource stub page and place it somewhere where I can provide access. For instance, I can put it near privacy policy file that is publicly accessible.
Is there a more suitable way of addressing this issue or some of these options might still work?
I've got a website that requires a login, this website shows a "portal" which makes it possible to go to deluge/plex/sonarr (webapps). these apps are connected to ports. so example.com:83031 = plex and example.com:83032 is sonarr (as an example).
Now if I go to example.com it prompts me a login and I if I then click on "plex", the portal goes to example.com:83031. this is correct. however, is there a way to disable a direct link to example.com:83031 (so is there a way to ONLY make it able to enter that site through portal?)
Long story short: I want example.com:83031 to ONLY be available through the portal, not if you enter it directly into the browser. is this possible?
[Editted the domains, got the point!]
In theory, a browser should send a "redirect" indicating from where you came. Hence, example.com:83031 could check if you came from example.com:80. This is however not reliable.
However, if you redirect to example.com:83031/loginOK?<GUID> then you have explicitly encoded the redirection information, in a way that no browser can strip.
BTW, don't invent non-existent domains. example.com exists for a reason.
Using reverse-proxy on Apache has fixed this issue.
Picture describing the outcome
I am unable to open Google, Youtube, some other website in my browser. Its showing a Certificate authentication error.
I changed it as a trusted website. Now it showing like:
(Index of /[ICO] Name Last modified Size Description)
I have no idea what to do. I am unable to google.
Other websites like facebook, yahoo and Gmail load correctly in the browser.
This is the message in google-chrome:
Your connection is not private
Attackers might be trying to steal your information from
www.google.co.in (for example, passwords, messages, or
credit cards). NET::ERR_CERT_AUTHORITY_INVALID
The Message I am getting in chrome when I click advanced:
Hide Copy Code
www.google.co.in normally uses encryption to protect your
information. When Chrome tried to connect to www.google.co.in
this time, the website sent back unusual and incorrect
credentials. Either an attacker is trying to pretend
to be www.google.co.in, or a Wi-Fi sign-in screen has
interrupted the connection. Your information is still secure
because Chrome stopped the connection before any data was
exchanged.
You cannot visit www.google.co.in right now because the
website uses HSTS. Network errors and attacks are
usually temporary, so this page will probably work later.
Is this a problem with google servers, something in between or the client side browser? Is there a workaround for this error?
This is a Chrome issues. Switch to a different browser and you will be fine. Google has decided to make getting to sites without the "expected" SSL certificate almost impossible (you can go clear the cached cert info on a site-by-site basis, which is a real pain...but expect the problem to come back again and then you have to go clear the cached cert again).
If you are using web filtering or various real security products that decrypt / inspect / then re-encrypt traffic, Chrome dumps all over it.
I used to be a Chrome fan, but because of this issue I had to abandon Chrome. I'm not going to turn off my real security products just so I can keep using Chrome!
My organization had a web app that worked perfectly in iOS 6. You'd visit the website, the website would tell you to add the page to your homescreen, and boom, a nice HTML5 web app was added to the home screen.
Because we're processing sensitive data, the web app used HTTP authentication (via the native WebKit auth dialog) to authenticate user/passes. It worked without a hitch until iOS 7. Now when someone tries to summon the HTTP auth dialog, nothing happens. It's clearly trying to load something, as the spinner in the status bar appears, but no dialog ever pops up, essentially breaking the "app."
Has anyone else run into this? Is this something you'd consider to be a bug on Apple's end? Any workaround?
My company ran into this last fall, starting with iOS 6, and what we have been able to ascertain is that it is a genuine Apple Safari bug as part of its security "enhancements". No real explanation from them for rationale, but here is what we see in the debug and packet sniffers.
In normal operation, the Safari browser will request a page (or an object in the page) from the server on a GET. If that asset is protected with an Access Control List, in our case Apache Basic Auth, and it is the first request on that host in the session, the server will respond with a 401 HTTP response header indicating to the client (the browser) that it needs to request again, this time adding a basic auth header that has authorization credentials. The browser then presents a login dialog to the user, where they can enter user and pass credentials, and either submit or cancel the request. On submit, the client re-requests with those credentials in the auth header.
Assuming the credentials are accepted on the second GET request, the proper asset will be returned on the response, and the document in the browser will proceed with loading the rest of the page (assuming it was a page you requested). If you have embedded assets that reside on a different host, and that host requires authentication for that asset, the process is repeated as the page loads.
Here's where it gets broken. If you embed calls to objects from more than 2 hosts total on the same page, which require basic authentication, the 3rd authentication prompt on that page is suppressed, so the browser spins forever waiting for you to enter credentials on a prompt that you never see. Your Safari browser is now hung up on that stalled authentication prompt, on this and any other tab, even on a reload, and you will not get another prompt unless and until you hard-close your browser or restart your device.
This does not affect Chrome, just Safari, and it is both on an iPhone and an iPad with iOS 6 or later. I have the latest iOS version as of this writing (7.0.6), and the problem is still there.
We had a workaround last year, where we would create an internal page that had an array of each of the embedded hosts, which we would then loop through with an iframe embedding a call to the favicon.ico at that host's location. That worked until recently, where now, perhaps because of the iOS 7 feature of freezing background tabs, the auth prompts are frozen up again.
Here was the JavaScript sample:
hosts=["store","profile","www","secure-store","images","m","modules"];
devhost=location.hostname;
var i=0;
while (hosts[i])
{
newhost=devhost.replace('store.mydomain',hosts[i]+'.mydomain');
document.write("<iframe Xhidden seamless=seamless width=0 height=0 src=http://"+newhost+"/favicon.ico><img height='16' width='20' alt='NOT' title='NOT AUTHENTICATED' src=http://"+newhost+"/favicon.ico> Authenticated on "+newhost+"</a></br></iframe>");
document.write("<img height='16' width='20' alt='NOT' title='NOT AUTHENTICATED' src="+(newhost.indexOf('secure')>0?'https://':'http://')+newhost+"/favicon.ico> Authenticated on "+newhost+"</a></br>");
i++;
}
The second set in the document.write would give a visual indication of which hosts have been authenticated, as their favicon is now displayed. It also lets you know which host might be stalled, as its icon is missing.
Since this workaround stopped working on iOS 7, the only cumbersome solution we have is to pre-open a separate tab for each of the favicons (directly in the URL), enter the auth, go back, go to the next one in the list, and repeat until you have cached all of the auth credentials for all of the hosts used on the page. At that point, you can load the original page since your creds are now cached. Cruddy, and completely unreasonable for an end consumer, but is what we need to do for testing sites that are behind a public CDN, as we need to protect assets on that development site with an ACL.
As of today, we are still figuring out a better workaround. Not an issue on Android, Windows, or any other iOS.
Sure worked better when Jobs was alive.
Hope some of this helps.
I have the exact same problem. Basic authentication worked with previous iOS versions but not with iOS 7 in combination with web apps added to the home screen. I think this may be related to the dialog problem described here.
Standard dialogs are not working at all, such as alert, confirm or prompt.
The login prompt that is shown to authenticate the user is probably blocked (does not work or is not visible) and that is why the web app does not pass through the authentication phase.
I suppose Apple will have to fix this bug in a future release.
Edit: After upgrading to iOS 7.0.3 basic authentication suddenly started to work again also in home screen web app mode. Login prompt is displayed and everything works as expected.
When I go to a place with a WiFi hotspot (such as Panera Bread) and connect with my iPhone, the hotspot login page appears as a popup. That is, no matter what app I'm running or what web page I'm on, the login page scrolls up from the bottom, asks for my login credentials, and then disappears.
But at some other hotspots, I don't get the login page until I go to Safari and try to load a web page.
What is the iPhone looking for that causes it to pop up the login page at some hotspots and not others? Is there a special HTML meta tag? Or is it related to the way the redirect is implemented?
I managed to find out the correct term for this authentication type: "Captive portal". Punching in Captive Portal iPhone into Google turned out a few technical details from these pages: one, two, three.
To implement a Wi-Fi popup login page:
DNS request for www.apple.com must not fail
HTTP request for http://www.apple.com/library/test/success.html with special user agent CaptiveNetworkSupport/1.0 wispr must not return Success.
I have not tested this, but it sounds about right.
Comments below mention that iOS 7 behaves differently and may query more than one server. I have not tested this. So easiest would be to simply redirect all HTTP communication to your login page, and block all non-HTTP communication.
Microsoft's captive portal detection uses something similar to pre-iOS7 behavior: its Network Connectivity Status Indicator attempts to contact http://www.msftncsi.com. Windows 8 and 8.1 also include support for WISPr.
Android's captive portal detection, as of AOSP 4.0.1, tries to contact http://clients3.google.com/generate_204 or http://www.google.com/blank.html.
So to be as universal as possible, you'll want to simply block all communication except for authentication, and include WISPr support on the login page.
I'd say "go with a proper authentication on your network" -- something universal such as PEAP+MSCHAPv2 -- but Windows makes it very painful for your users to set it up. I don't know who thought that "Use your Windows authentication details" makes a sane default on machines that are not part of a corporate domain network, or even why "Check certificate validity" is a sane default, as most networks will not consider getting a proper certificate a priority.
iOS 6 has apparently fixed WPA2 EAP as it's suddenly popping the login window now.
Our companies public WiFi requires accepting the terms regarding monitoring, etc. I always had to manually open Safari on iPhone or iPad and navigate somewhere, it redirects to an internal acceptance page and when you clicked the Accept button it would go where you originally were headed.
Today, I updated to iOS 6 and was plesantly surprised to see the Login window slide up from the bottom and allow me to click the Accept button without even opening Safari.
I suspect that when the login page pops up the Wi-Fi is using EAP. This is a Wi-Fi protocol for authentication. In the case where you need to go to a web page then the authentication will be a custom access implemented by a server (i.e. at a higher level
than EAP).