Now, this sounds very strange but we have an application which supports only particular browsers and in order to keep a close look on alll the requests coming, we have a log server which logs all the detailed information about incoming request's userAgent.
Now, some of the IPad users complained that they used to see NotSupported.html page, which is the page we redirect users to when the page is not supported. They ONLY see it sometime.
We we looked at our logs and sometimes Ipad requests were coming a Mozilla 0.
I am using HTTpRequesBase's UserAgent Property to read it. and I am not sure why IPad identifies it self as mozilla 0 and that also ONLY sometimes. Anyone ahd similar experince?
Safari is not the only Browser in the Apple devices.
When I go with my Chrome for iPhone to http://www.whatsmyuseragent.com it shows Mozilla as well. So the best assumption is that those users are not using Safari.
EDIT: It does come with enough information to know it is an iPad, I myself have a project that matches iPad in the User-Agent string and works for Chrome/Safari and I don't have Opera to test right now but I guess it works too (anecdotal on no complaints).
Related
I tried to search on the internet for this. I got a related question here but could not get a convincing answer.
I have a web page built in asp.net. I have google recaptcha on this page and is working fine on all desktop browsers and android mobile phones.
The problem is with iphones. The recaptcha does not show the image grid for the user to verify them. When the user touches the checkbox is simply gives a "tick" and lets the user through.
The model of iphone I have checked in is iphone 5C (safari) and iphone 6S (chrome 50) but I think the problem should be with all the models.
Please note it is working fine on simulators like chrome simulators.
The web page is as below:
http://www.infochoice.com.au/infochoice/contact-us.aspx
This is a live webpage so request you to please be careful and gentle in adding comments in it.
I have not added any code here in this question as I think it is more iphone device specific issue and has nothing to do with code.
Will update the question if requested.
Please help! Thanks in advance!
reCAPTCHA actively considers a user’s entire engagement with the CAPTCHA—before, during, and after—to determine whether that user is a human.
In cases when the reCAPTCHA risk analysis engine can't confidently predict whether a user is a human or an abusive agent, it will prompt a CAPTCHA to elicit more cues, increasing the number of security checkpoints to confirm the user is valid.
Therefore some users may just be shown a simple checkbox while others may face image grid verifications.
See this blog post for more details
https://security.googleblog.com/2014/12/are-you-robot-introducing-no-captcha.html
We have a link that goes to Google Maps for directions using just the normal format for the Google Maps URL: https://www.google.com/maps/dir/Current+Location/38.8992,-77.0482.
This works fine on google chrome and other browsers don't seem to have this issue either, but somehow on the iPad with OS 8.1.3 using the Safari browser, an alert comes up with the message "Safari cannot open the page because the address is invalid"
Is anyone else experiencing this issue?
The page still does seem to load, but the alert pops up and needs to be dismissed and detracts from the user experience. Since the link follows the Google Maps API standard and seems to work otherwise, what is the reason this is happening and what can be done to stop this from happening?
Also, something strange happened when after the link works a few times, the message no longer comes up when the user is directed to the page. However, after clearing history and data for the Safari browser on iPad, the problem resurfaces again.
In case anyone else arrived here but wasn't getting this error because of a Google Maps link, Look at any JS you have listening to the click event of the link.
In my case, I had discovered a previous developer added a
e.preventDefault();
to the click event.
It may be worth noting that--as a PhoneGap developer--I've verified that the iOS's GPS data appears to be higher quality than that, say, on the Android phone or on an HP laptop. The number of digits of precision on the iPad is significantly longer than what's available on other platforms.
It could be that when iOS is pushing so many digits of precision that their server is seeing this as an error. This discussion appears to suggest that Google will throw away unnecessary precision but it's possible that a recent update now at Google Maps is choking on the excess.
Also note: if your phone is set for a language other than English then the Google API expects the word in that language for "current", for example, "votre+location" in French.
I created a router that connects to facebook to get some info before a user may access the internet.
First they connect, get the Captive Portal Page and then continue to a facebook login. Since the upgrade to iOS7 it fails to load the facebook login page. On my mac with the Captive Portal Assistant it has no problems and even on the phone itself while using the iOS version of safari there are no problems.
What is going wrong here? Is facebook filtering request from the iOS7 Captive Portal Assistant or is Apple doing some sneaky stuff here?
It seems the problem is widespread and only related to facebook.
Update: I worked with the beta's and they worked fine a few weeks ago. Now with the same beta version it doesn't anymore. So another point for the facebook explaination.
Regards, Cas
This problem was fixed by Apple since IOS 8. But as all iPhone 4 users can't upgrade to IOS 8 this problem is still one.
The IOS 7 devices check for the following domains:
www.appleiphonecell.com
captive.apple.com
captive.apple.com
www.apple.com
www.itools.info
www.ibook.info
www.airport.us
www.thinkdifferent.us
Whitelisting this domains stops the login mask to be appearing as the IOS device thinks, that the internet is working as expected. This way you have control on the things which happens, as the IOS device does not interrupts anything, if you use a normal browser for login.
If you don't whitelist the domains, the following thing happens. I debugged it on routers with several IOS devices and they all did mostly the same:
If you connect to a wifi, the IOS device tries to connect to one of the domains, which are listed above. If it can contact one of the domains, it tries another one. If it can't, it starts the redirect, which is controlled by the router. Sometimes it query one or more domains, before it thinks, that the internet is working.
After the check, the login screen redirects to your router and then to the login screen of your captive portal. This behavior stayed the same as it was on IOS 6 or before.
Now you start an oauth login to a 3rd party provider like Facebook, Google or Twitter. And now the difference appears. You can check it on a router, if you run it in debug mode. As the IOS device goes to an other domain for oauth login (like www.facebook.com) the iPhone thinks, that something changed and starts to query one of the apple domains, which are listed above. The user sees only a white screen and in the background the IOS device tries to contact one of the domains repeatedly. For the user this seems to be an error, as the screen stays white or takes very long to show the login on the 3rd party provider. Sometimes it stops loading and nothing happens forever.
To avoid this behavior, you must whitelist the above listed domains. This is a not a common behavior for IOS users, but this way, your browser have the control of the login session and the IOS device don't interrupt it as it does with the login screen.
Some shallow parts of information is reported on the following sites:
https://supportforums.cisco.com/docs/DOC-36523
http://www.cadincweb.com/why-your-apple-ios-7-device-wont-connect-to-the-wifi-network
https://discussions.apple.com/thread/5355766
I couldn't find a detailed description of the problem and found the one above myself by debugging all parts with some routers and IOS devices like iPhones and iPads.
I've just tested various router settings and noticed that iOS 7 is NOT trying to contact above mentioned sites/URLs when router's DOMAIN field is blank.
My guess is that blank domain points to a consumer-type network set up and Apple is not expecting a Captive Portal at such network. If you have access to administer your router see if you can clear out the DOMAIN field (and restart/retest).
I found my solution to my problem. (a while ago, but I found this post again)
First I found out, iOS makes 3 calls, first to check, second to get the page that needs to be displayed, third to check again after the pageload. Then I discovered, for every POST or GET action made by the page, regarding of the source page was refreshed, iOS checks for an active internet connection. Since the facebook api makes a lot of calls, the browser starts stalling(possible in combination with QoS on my router) and freezes the page.
My Solution:
Since I am in control of the DNS records of the Router I use, I redirected all domains towards my own server.
First I saved the check request, this to later identify the user when he comes back for the 3th request.
When the second request comes I just display an info window that every thing is right, and the user has to click the "Done" button.
The page is loaded, so iOS checks again, but i recognize the user so I display the OK-code Apple also displays. The "Done" button us show, and the user has "internet", according to iOS..
On the page that I display, I instruct the user to open the webbrowser. When he does, he opens a page and my portal with the right page is shown(I can detect this based on the Browser Agent). Then my facebook api start doing its job, and of we go :-)
Let me know if someone needs some more info on how to detect or maybe even a code sample if necessary.
Extra Information
To capture a user on your own server, redirect every request to your processing page using for example .htaccess. The request is made to a domain with a subfile e.g:
http://captive.apple.com/getrT09Nx7G/YNrnUOulnDj/3cfrq3M40iR.html
To keep multiple users apart, use the unique url the device tries to contact when checking for internet, in this case: /getYT09Nx7G/YN1nUOulnDj/3cfMq3M40iR.html
I've setup a Captive Portal with dd-wrt, wifidog, authpuppy and some plugins from authpuppy as well as my own web app.
I am wondering what's the exact thing that will trigger a
browser on the client device to popup?
Is the popup browser from iPhone/iPad a regular browser mode?
It seems some JavaScript will fail on the browser mode, like the shake.js,
event though iOS Safari version is > 4.2.1 from https://github.com/alexgibson/shake.js/
P.S.:
I've done the research like
http://en.wikipedia.org/wiki/Captive_portal
https://personaltelco.net/wiki/CaptivePortal
they don't talk much about the popup browser.
Could anyone help?
If you will try to see the network statistics [request/response] you will find out that devices like ios and android both of them continuously hits some particular urls [in case of android it is www.google.com/generate_204 , don't remember exact url for ios]. These url are generated by system internally. These pings let their server know about various details. So as soon as ios gets connected with a captive portal it tries to hit the system generated url, failing to which it understands that this is packet level protected network and open the browser.
Hope this helps.
I am trying to create an application on BlackBerry 9930 simulator that authenticate the user with Facebook, using the BlackBerry Facebook API. It connects to the login page fine, but after that the entire application crashes, either when asking to review the permission or when the login has succeeded.
I noticed that the authentication process went well since I get a message from Facebook that there is a login, so I am suspecting either the problem with the browserField and/or the simulator. (I tried 3 different BB 7 simulators, all the same though).
Anyone has a way to resolve this? Thank you so much.
It seems that no one has any solution for me :(. But, after messing around with it, I have found an explanation and a solution for it and I think I should share this with you. Sorry for the lateness in the response, though.
Here is the story.
As you probably already know, after supplying the credentials, Facebook returns the access token in the URI which is followed by the # symbol. Now, the BlackBerry Facebook API overrides the handleNavigation() method to ensure that, if the URL contains the access token, it will not be processed. This used to work in earlier versions (prior to BB 7) but somehow, it seems that URL redirection in BrowserField are no longer calling handleNavigation(), but rather handleResource() directly (I don't know why and, to my knowledge, there is no documentation for this change anywhere). The result? It always tries to process the URL that contains the #access_token in it.
Worst, the BB BrowserField thinks that # means a jump to a portion of the page (which doesn't exist). Other browsers (including the BlackBerry Browser) seems to understand that already and print only "Success" on the screen, while the BrowserField does not. And when that happened, the application just stopped working and crashed, sending me back to the home screen.
So what I did was I changed the source code of the BlackBerry Facebook API so that handleResource() now checks by itself whether the access_token is in the URL. Then, the application works fine.