I have trouble with RN-webview when rendering my page on IOS machines in China.
For the details,
My page(server) is in Korea and clients are in China.
When trying to access page via browser app and pure swift WKWebview app, my page can be rendered.
When trying to access page via RN-Webview, can't render my page.
(NSURLErrorDomain Code=-1005. The network connection was lost.)
So, I think, there are some difference between RN-Webview and WKWebview so they makes this error.
For the first step, I'm going to check what kind of default values are set in request header of WKWebview.
It is because my page is failed with -1005 error which is about connection.
When google this issue, many people said it can be about header issue.
In the nutshell, where can I check the default values of WKWebview and RN-Webivew request headers?
I'm developing an app using Phonegap and it implements a Facebook login to save some data using the user_id as a reference. I'm using OAuth.io library to implement the login dialog and everything runs smoothly in the web browser and in Android but when I test the app in XCode and I tap the login button the following error appears.
Cannot find hostname in file:/// from static
code: InvalidHeader
message: Cannot find hostname in file:/// from static
My guess is that it has something to do with phonegap not making an external request since the app is not actually hosted in a domain but running locally... any thoughts?
Seems like you are using oauth.js library instead of phonegap version
In your main page "index.html" add reference to the correct js file
<script src="oauth-phonegap.js"></script>
Then follow the instructions here to build your application
I had a simular issue using oauth.io. Turns out it was my Ajax prefilter changing the REQUEST to Facebook(it was adding parameters to the header for each request). Wether this is your issue or not, what you need to do is compare a successful REQUEST to Facebook to an unseccussful one, that will show you where things go wrong. Alternativly a blank phonegap app with no extra code other then the required oauth code should work and will be a Good starting point to isolate your issue.
I have been using Phonegap 2 years before.Though I didn't connect to facebook before,I connected to other website by OAuth.I can show you my solution.
Firstly,you should know how OAuth works.You can read OAuth 2.0 from facebook developer website or other websites.
Secondly,you should know your target:token,uid,expires_time.The most important thing is token.
Thirdly,just do it.In 2010,I solve this problem by using Phonegap Childbrowser plugin(now Phonegap have a inAppBrowser) and a light server.
Why I should use a light server?The server can help me to handle the redirecting in OAuth service and do cache.
Step 1 : I wrote script to connect with my server,and my server connect to OAuth Service(facebook).
Step 2 : OAuth Service(Facebook) do response and redirect to Facebook login page.
Step 3 : After input username and password,OAuth Service(Facebook) will redirect to another url and do a callback with some code or token.
Step 4 : If you get the token,save it and use it to connect OAuth Service(Facebook) if you want.
When I saw "Cannot find hostname in file:/// from static " in your description,I know that maybe you get confuse in OAuth.Now,I suggest you some server side code to handle it and make your OAuth process possible.
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.
Trigger.io has just updated today and we found the new UI great! But when we run our Application to android Emulator, we suddenly found this issue:
[ERROR] XMLHttpRequest cannot load http://site.com/api/. Origin content://com.sample.android.app is not allowed by Access-Control-Allow-Origin. -- From line 1 of null
[ERROR] Uncaught SyntaxError: Unexpected token o -- From line 1 of
We are trying to access the api and then an error occured. It is working fine in Iphone but having a trouble in Android.
I hope trigger.io can address this issue please.
Trigger apps on Android are served via content:// urls which means they are not permitted to make requests to other domains, on iOS file:// urls are used so this restriction is not in place.
You have 2 options to fix this, either set the Access-Control-Allow-Origin header sent by the server to *, or use forge.request.ajax to make the request. forge.request.ajax uses native code to make the request and so avoids any Javascript security limitations, more documentation is available here: https://trigger.io/docs/current/api/modules/request.html
I am in the process of creating an iOS app with Phonegap and jQuery, however, I am running into issues trying to allow both iFrames (to load normally) and external URLs (to open in Safari). I decided to choose the path of using iframes as I was not able to send POST and open the resulting page in Safari (i was trying to create a mobile friendly login window that opens to the full site in safari).
I recently updated to v1.5 hoping to resolve the issue, but it still occurs.
I have tried the trick "[url scheme] isEqualToString:#"http"...." however this forces any page in the iframe to load in safari.
So, I would like either to have external URLs and iframes to behave just like it does in a Webapp (add to homescreen button on iOS) or be able to send POST to Safari?
Has anyone got ideas? :)
Thanks!
You could change tactic slightly and login fully using your app, but then create an authentication token which would be passed via a standard link to be opened in safari.
You could generate the token new each time. Tokens are a valid system for access.