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?
Related
I'm trying to use the Google Picker API to display a picker for the user to select a file. I have this working great in a web app (in a normal browser), but when I run the same code in an electron app, I see a 400 message in the popup iframe, and get the following console errors:
Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://docs.google.com') does not match the recipient window's origin ('file://').
Failed to load resource: the server responded with a status of 400 ()
The core problem seems to be that the electron browser window has an origin of file://. This seems to cause two problems:
The (chromium) browser security blocks the cross-origin iframe communication
Google rejects the request as not coming from a valid origin (and you can't add file:// as an origin in the developer console)
I can't think of any way to overcome these problems, but I'm hoping that someone has an idea.
You could create an app and host it in something like following, and then point the electron BrowserWindow to the url.
https://app.yourdomain.name/gdrive/picker?token=access_token
That should work I believe.
I am developing a WKWebview app in swift. Here One needs to login to a specific domain. For this , I am throwing a cookie with logged in information/token.
But the problem occurs when I try to logout and the check if token exists?
And the token still exists even after logout.
Note - I checked on chrome browser on mac, and here it works perfectly.
WKWebView runs all of its networking in a separate process and thus does not ‘see’ your process’s cookie store.
The problem is that the WKWebView does not write back the cookies immediately. I think it does this on its own schedule. For example when a WKWebView is closed or maybe periodically.
In iOS 11 we added WKHTTPCookieStore to give you full access to the web view’s cookie store.
Supported cookie sync with WKWebView on older platforms is tricky. There are two techniques that might work:
You can set a cookie in the headers of the request you pass to
[WKWebView loadRequest:].
You can get and set cookies from within the web view by running
JavaScript code (using -evaluateJavaScript:completionHandler:) that
accesses the JavaScript document.cookie value.
For more reference https://forums.developer.apple.com/thread/95301 additionally some workaround Getting all cookies from WKWebView
I have a common web service used by a web application (internet browser access) and by a mobile app.
My iOS app loads a local html file in a WKWebView and calls this web service using javascript/ajax so as per new CORS implementation in WKWebView I must add an 'Access-Control-Allow-Origin' header to the response. I will add this header only when coming from the app and not when coming from a web browser - for security reasons.
If I set Access-Control-Allow-Origin to * everything works as expected. However I would prefer to prevent the access from anything but a local page. I have tried to set it as null and it does not work in WKWebView - but it is working if I open a local html page in Firefox that makes the ajax call.
Is is possible to achieve this in WKWebView? I have only found this https://issues.apache.org/jira/browse/CB-7348 where the person said "The only solution is, the destination server MUST return the header "Access-Control-Allow-Origin" that matches the wildcard or "null"" but it is not working on my side (iOS 10/11)
I have a website that is iframed into a 3rd party webpage, which is itself embedded in a WkWebView in an iOS app. Mobile Safari and the WkWebView reject the session (http-only) cookies being sent for my website, breaking basically everything. The work-around in mobile Safari is to either enable all cookies in settings (yuck) or instruct users to visit my site directly (so it counts as a "site I visited", as far as Safari is concerned); neither of these is particularly palatable. I have found no work-arounds for the WkWebView.
This question is two-part:
1) I am thinking of implementing a redirect service in my website, that takes a destination URL as a parameter, and simply redirects the user to that URL on page load. The 3rd party site can then link to my redirect page with the URL set to send users right back, with the hope that this will count as "visiting" my domain, enabling cookies to be loaded.
Alternatively, the 3rd party site could open a new tab to my site, that closes immediately on load. I expect that this would be a less optimal user experience, however, and so would prefer not to go this route.
Best of all would be for the "POST to a hidden iframe" trick (3rd party page POSTs to my domain in a hidden iframe), but as SO questions indicate that trick no longer works.
Are either of these viable solutions, or has Apple blocked these methods of getting the session cookies set as well? Is there a better solution that I have not considered?
2) Is there a way to set the cookie acceptance policy with WkWebViews like could be done with UiWebViews? My searches of StackOverflow suggest not, but the answers I read could be based on older versions of iOS (the app requires iOS 9+).
If there is no app-code solution for WkWebViews, would the solutions for mobile Safari also work with WkWebViews?
I just had a similar issue. I have a WkWebView which loads my web app that has an iframe loading a login screen from a specific server. The login page would complain that the iframe did not allow cookies.
When I would load the login page directly in the web view, it would work and it would also curiously start working as well when I tested it afterwards again inside the iframe.
The best explanation I found for this is, cookies are only allowed to be saved in the iframe if the web view has directly loaded the domain of the iframe at least once. Knowing this, I was able to implement a workaround.
By simply pinging the login page once with the webview, I use the WKNavigationDelegate to wait until I start receiving some data from the server. Once this happens, I make the web view load my page that contains the iframe. Now the iframe is able to consistently load the login screen.
Our app has a UIWebView with an iFrame inside it, and the website the iframe points to requires basic authentication.
In a browser the alert popup displays and allows us to log in, however in the UIWebView it does not.
Is there a setting or something we've missed?
Chris
As stated in the official Developer forums and as for now, UIWebView does not support authentication challenges in iOS. Please read here (requires developer account): UIWebView does not directly support authentication challenges
A workaround is to load the html in NSURLConnection (or NSURLSession), execute the authentication challenge and then assign the data the web view.
That won't work in all scenarios, though.
Some time iFrame URL try to load from the cache.
Try to set the response header Cache-Control:no-cache.
401 Authorization requests will be blocked because of the cross-origin request