Open zach-klippenstein opened 11 years ago
Figured out why my captive portal detection app wasn't working at Starbucks hotspots. I'm using Apple's page to check for proxies, which consists of a single line of simple HTML. Before signing in, all my browsers and a REST tool I grabbed off the Play store returned the Starbucks terms of service acceptance page. My detector, however, returned the page as expected when not behind a portal, with one difference: it included a W3C prefix. Upon further inspection, the response headers also showed it was coming from a Microsoft IIS server - probably not what Apple is using to serve their pages. Those headers were also missing from a known correct response. I had thought at first my HTTP client might be locally caching the "success" response, but that obviously wasn't the problem.
Then I noticed I had, for some reason early on (about a year ago), decided to use the following user agent string in my request: CaptiveNetworkSupport/v1.0 wispr
. I think the site I read explaining how iOS devices detected portals mentioned that they used this user agent string, and I thought it would be a good idea to do the same - couldn't hurt. Well, I was wrong. Turns out, the price Starbucks is using returns a fake success page to any clients using that user agent string. This only started about a month ago, when my detection app started malfunctioning, and I also noticed my Macbook was no longer popping up the acceptance page either.
I removed the user agent string, and the expected page was returned. Does anyone know why Starbucks is trying to actively fake out iOS devices?
Portal detector starts, log shows which portal detector implementation is being used, then fails to detect the portal.
Confirmed at Canadian Starbucks.