I´m trying to load a URL to a webview.
Let´s say the url is: http://www.somepage.com/
But for some reason when I load the url in the webview, it adds a m. (URL looks like this: http://m.somepage.com) , it seems like it´s trying to add a mobile version of the website. There isn´t a mobile version of the website, so it´s trying to load a url that doesn´t exist.
In the shouldStartLoadWithRequest delegate method for the webview, it returns the correct URL. In the didFailWithError method I can an error saying: Error Domain=NSURLErrorDomain Code=-1003 "A server with the specified hostname could not be found." UserInfo=0x5a7c670 {NSErrorFailingURLStringKey=http://m.somepage.com
Any idea how I can fix this? Can I replace the m. with www in some way?
This is most certainly an issue with the webserver. It is redirecting your requests to a domain that does not exist. If you have access to the webserver's configuration you will need to fix this there.
If you don't have access to the webserver, your only chance at avoiding this particular issue is to send a different User-Agent string so that the webserver no longer thinks you are viewing the page from a mobile device. However, there doesn't seem to be an easy way to do this on a site-by-site basis.
Relevant Stack Overflow Question:
Change User Agent in UIWebView (iPhone SDK)
I am using the UIWebView without any issues. Can you check whether the site you are accessing has code that redirects to a mobile version?
Related
I did not find an answer to the question of how to do this in flutter.
The problem is the following:
when requesting permissions for geolocation, first the first window pops up directly for the application itself, then the second one for the WebView.
So the request for the WebView looks just disgusting, all because I'm running the WebView
locally(without a local server).
I found a similar article but it is directly for Swift, I could not figure out how to adapt it for Flutter: How to prevent WKWebView to repeatedly ask for permission to access location?
Actually my question is:
How can I get rid of that second request? Because it sure isn't great UX...
first nice request for app
second ugly request for webview
So I cannot find any reason I am seeing the below behavior and if anybody has some insight it will be greatly appreciated.
Basically I am using the FB.UI from the JavaScript SDK to send a message to a user with a link. The link ends with a Guid, like http://www.domainname.com/register/33a1a0ae-e0fe-4eb6-9bf9-146d5492e3d6. This works sometimes, but occasionally fails with a generic 500 error from FB.
I have pulled out the HTTP POST request and have found a solution that I can recreate, unfortunately I cannot share the access code to allow SO users to actually run it (I replaced all sensitive parameters). Below are two identical requests that differ only in the Guid. The first succeeds every time and the second fails every time. I have numerous Guids that are doing this which makes if unreliable.
https://www.facebook.com/dialog/send?access_token=XXX&api_key=XXX&app_id=XXX&channel=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D5%23cb%3Df2cb8f5c1ca0402%26origin%3Dhttp%253A%252F%252Fwww.domainname.com%252Ff350c0fd55d5764%26domain%3Dwww.domainname.com%26relation%3Dparent.parent&channel_url=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D5%23cb%3Df11a615f3b71192%26origin%3Dhttp%253A%252F%252Fwww.domainname.com%252Ff350c0fd55d5764%26domain%3Dwww.domainname.com%26relation%3Dparent.parent&description=test&display=iframe&link=http%3A%2F%2Fwww.domainname.com%2Fregister%2F**33a1a0ae-e0fe-4eb6-9bf9-146d5492e3d6**&locale=en_US&name=test&next=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D5%23cb%3Df22e359d88321ce%26origin%3Dhttp%253A%252F%252Fwww.domainname.com%252Ff350c0fd55d5764%26domain%3Dwww.domainname.com%26relation%3Dparent%26frame%3Df33c13cd4ecc156%26result%3D%2522xxRESULTTOKENxx%2522&picture=http%3A%2F%2Fwww.domainname.com%2Fimg.gif&sdk=joey&to=XXX
https://www.facebook.com/dialog/send?access_token=XXX&api_key=XXX&app_id=XXX&channel=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D5%23cb%3Df2cb8f5c1ca0402%26origin%3Dhttp%253A%252F%252Fwww.domainname.com%252Ff350c0fd55d5764%26domain%3Dwww.domainname.com%26relation%3Dparent.parent&channel_url=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D5%23cb%3Df11a615f3b71192%26origin%3Dhttp%253A%252F%252Fwww.domainname.com%252Ff350c0fd55d5764%26domain%3Dwww.domainname.com%26relation%3Dparent.parent&description=test&display=iframe&link=http%3A%2F%2Fwww.domainname.com%2FFregister%2F**dd171262-dbcc-43c3-b9d1-e37dc53e3520**&locale=en_US&name=test&next=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D5%23cb%3Df22e359d88321ce%26origin%3Dhttp%253A%252F%252Fwww.domainname.com%252Ff350c0fd55d5764%26domain%3Dwww.domainname.com%26relation%3Dparent%26frame%3Df33c13cd4ecc156%26result%3D%2522xxRESULTTOKENxx%2522&picture=http%3A%2F%2Fwww.domainname.com%2Fimg.gif&sdk=joey&to=XXX
I tested both of these urls:
http://www.domainname.com/register/33a1a0ae-e0fe-4eb6-9bf9-146d5492e3d6
http://www.domainname.com/register/dd171262-dbcc-43c3-b9d1-e37dc53e3520
with the js sdk send method, and indeed the first url resulted in a 500 from facebook, while the first managed to send it.
I can't understand why the first UID triggers an error while the second does not.
The reason I kept asking for a working example of such urls is that when you share a url using facebook, they scrap that url (unless it's already in their cache) and extract meta data of that url so that a feed story can be composed.
Since the urls that I was trying are not accessible for facebook it might somehow trigger that error.
If I try this url:
http://laine.webhop.org/tresendas/register/33a1a0ae-e0fe-4eb6-9bf9-146d5492e3d6
then it works and I don't get the server error, even though it has the same UID as the first url I tried.
I suggest that you try to use urls accessible to facebook, if you still get errors for certain UIDs, then you should probably open a new bug report.
I got problem when loading Facebook Javascript SDK, it will causing my SSL connection partially encrypted. I try load not using the asychronous one but the result same. Do you have solution for this problem guys?
Thanks
#andriansandi
the code facebook gives to implement the JS SDK uses a protocol relative URL ... The URL of the JS file is //connect.facebook.net/en_US/all.js.
By not specifying http/https the browser will automatically use whichever protocol the page was requested with. Try substituting that with https://connect.facebook.net/en_US/all.js. This will force facebook to load the SDK over https.
Problem
I have an application driving a tab on a client's page. The application works correctly if the user has not enabled FB's "secure browsing" feature. If attempting to view over HTTPS, the iframe doesn't even appear (no errors, no mixed-content warnings). When correctly loading over HTTP, the div with the id "pagelet_app_runner" has an iframe inserted into it and the application content is loaded inside there. Over HTTPS, this div remains empty and the iframe is not inserted into the page. There are no Javascript errors appearing in Firebug or Chrome's equivalent console.
Why I'm Asking Here
The host has a valid SSL certificate and there is no 'mixed content' at the URL in question. I can successfully view the content over HTTP or HTTPS by visiting the URL directly, and I can do the same by visiting apps.facebook.com/canvasURL/tabURL. It is only when attempting to view within a Page Tab that the HTTPS load fails as described above. My application is configured with both regular and secure canvas and tab URLs.
Attempted Debugging
I've recorded some sessions with Charles but since the iframe isn't being inserted into the page, I think I'm coming at the problem after it's already occured. I'm no Charles expert so happy to be corrected here.
Apache isn't seeing any request (in either regular or ssl logs) for the affected loads. non-SSL loads come through as expected in access_log.
Plea for Help
I'm out of ideas for debugging this. Does anybody have any suggestions? What really obvious and stupid mistake might I have made? :)
edit: nicer formatting
Your app canvas URL is https://skinnycomp.nextstudio.com.au/skinnycowcomps/ , which send 404 error to Facebook proxy (request is going through proxy when viewing app via tab), also when viewing your app via apps (https://apps.facebook.com/122381834451561/), again 404... maybe Facebook proxy is ignoring 404 and posting blank...
Try changing canvas URL to https://skinnycomp.nextstudio.com.au/skinnycowcomps/tab, also you can check if your app is accessed via page tab, in signed_request there should be page_id...
23:51:15.379[549ms][total 1667ms] Status: 404[Not Found]
GET https://skinnycomp.nextstudio.com.au/skinnycowcomps/
This is a real longshot since I'm sure you've triple checked all the settings, but the blank page can happen if an invalid url is specified in the Page Tab URL field in the app settings. Since it only happens on https, it would imply something specifically with the Secure Page Tab URL entry. It might be worth checking that again, and maybe even re-saving it or changing it to something else to see if it helps.
I was using relative URLs for the regular and secure tab URL fields. From memory relative URLs here were mandatory at some point in the past. It appears now that a relative URL will still work for HTTP but not for HTTPs. Fix: absolute URLs. Hopefully FB update their field validation to match what's required too.
A customer site that I cannot change has the line document.domain = "example.com" while the site is at www.example.com.
The effect is that FaceBook Connect window login gets stuck after submitting username+password.
Firebug shows its in infinite loop inside dispatchmessage function, which gives perpetual exception:
Error: Permission denied for <http://www.example.com> to get property Window.FB from <http://example.com>
Any idea how to work around this? I prefer not to ask the customer to remove the document.domain='example.com'
It seems like a really bad idea to tell the visitor's browser that the website is being served from a particular domain, when it in fact is not. The best solution would be to change that line. I take it you don't want to change it because they have some client-side code that depends on this?
One workaround would be to change the Facebook application's Connect URL to http://example.com, since Facebook's JavaScript will think that is where it is being executed.