A website I work on has a download pdf functionality, sending the proper HTTP headers in the response, to download the PDF file.
It works smoothly across the browsers (Safari, Chrome, Firefox etc), but recently we discovered it fails in the Facebook browser.
The scenario is that people would eventually open the website while navigating on Facebook, and may click the Download pdf button.
Facebook would show an error message saying Cannot render this kind of file or something similar, and the browser view would even crash (backwards/forward browser buttons won’t work anymore), bringing the user back to the Facebook feed.
Is there a classical issue to this problem? I tested using Facebook for iOS.
The headers we use are the following, as suggested here:
Content-Type: application/pdf
Content-Disposition: attachment; filename="filename.pdf"
I just guess this is a general issue, but after a quick search I can’t seem to find any information about it.
While it may be a Facebook, I’m just wondering what would be the recommended ways to fix this on our side.
In the worst case, I thought to hide the button if the user agent tells us that the user uses Facebook browser. But I just guess there should be better solutions.
There is no simple solution for this. The browsers from social apps will not download the files.
You will have to check the user agent of the browser and not display the download buttons (hiding the UI when needed).
Related
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.
I have read a lot of articles regarding universal links but still i need to be clear regarding few things.
I have to add universal links to http://www.domain.com but due to certain reasons i will not be able to make my website SSL certified or even put apple-app-site-association with https in root folder. So I thought of doing this in a different way, i will put apple-app-site-association file in the root of a subdomain, lets say https://www.app.domain.com/apple-app-site-association
Then i will open every universal link with that subdomain whenever universal link is available and redirect https://www.app.domain.com to http://www.domain.com if universal link is not available.
Questions in my mind :-
apple says - file needs to be accessible via HTTPS—without any redirects—at https:///apple-app-site-association.
In this line what does apple mean by without any redirects ?
when apple does not find any universal link related to a particular URL, will it itself redirects it to safari.
Is this a safe way to add universal links or is it necessary to have our main domain on https or at-least apple-app-site-association on https
This should work fine. To explicitly answer your questions:
'Without redirects' means when iOS requests https://www.app.domain.com/apple-app-site-association, it must find the file at that address. You can't have a redirect of any kind (Javascript, 301, 302, etc)
If a URL is not valid for Universal Links because you didn't cover it using the inclusion rules in the apple-app-site-association file, it will be opened using Safari. If the URL is on another domain without a valid apple-app-site-association file (e.g., http://www.domain.com/), then it will also be opened in Safari.
Yes, it's fine. Definitely a workaround, but not unsafe.
You should also investigate a hosted deep linking service like Branch.io (full disclosure: I'm on the Branch team) or Firebase Dynamic Links. These will give you all of the same benefits (plus a bunch more flexibility, to be honest) without any of the setup headaches.
We experienced ways where a 302 on iOS works.
In general I fully agree that Apple officially does not seem to support any redirect.
The following cases have been tested on an iPhone 6 running iOS 11.
These cases work :
Website in Chrome on iOS: User clicks on link A and a 302 redirects him to a Universal link B.
Website in Safari on iOS: User clicks on link A and a 302 redirects him to a Universal link B.
Gmail App on iOS: User clicks on link in email and Gmail opens external Chrome browser, which opens a Google link which redirects to link A which redirects via 302 to Universal Link B. (this case works only if Chrome is installed and in Gmail Settings the user explicitly changed the default browser to Chrome)
These cases DO NOT work:
Apple Mail: User clicks on link A in email and external Safari is opened. 302 happens and opens Universal link B. Result: App does not open
Gmail App: User clicks on link A in email and Gmail inAppBrowser (probably WKWebview?) is opened. Gmail redirects EVERY link from an email over a google server, as a second step link A is opened (dont know via 302 or other method) then 302 happens and opens Universal link B. Result: App does not open
Unfortunately you can see that in some cases it does NOT work. As these cases, Apple Mail and Gmail on iOS are very important for most of us here, I think this is a showstopper and you should not use it.
We tested with Adjust links and therefore in cases where the app does not open Adjust opens the AppStore to download the app.
For all Adjust interested: We tested by opening a link https://app.adjust.com/... which has a 302 on the respective Universal link https://XXXXXXX.adj.st/... on which our app listens.
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.
I am an ios app developer. We have implemented a custom URL scheme 'my_app://section_name' or so where if the link is opened in the user's mobile browser, it will redirect the user to a specific section in the app.
We would like to be able to tweet these URLs and have users on their mobile device click on them to open up the app, however it just can click once
(when you click close , maybe you click wrong then you want to click it second but it does not work )
I hope this isn't too silly of a question. Thanks
Make sure to check the tweet body after it have been posted.
This may be due of an URL shortener, especially if the tweet is posted from the iOS 5 Twitter framework.
I'm having a similar issue with url schemes. We can include them in emails and text messages, and they highlight and work properly.
Unfortunately, when we do the same with a tweet, the iOS Twitter client fails to recognise the special URL scheme and so the user cannot tap on it to open our app.
Pretty big oversight, methinks. Anyone else had any joy including special URL scheme links in tweets?
A solution that you should consider involves not sharing the URI scheme directly, but rather creating a page on your web server to handle this. In fact, if you want to be able to share full URI schemes with paths, you're better off building a web server to dynamically generate a page with a URI scheme redirect.
This is a over-simplified representation of what we built at Branch. This includes some code to get you started though the web server will require a bit of setup not described here.
instead of testapp://some.data.here, you'll link to http://yoursite.com/hosted-redirect/some.data.here.
your server should listen at the route /hosted-redirect, grab some.data.here and build the following page (body here):
(source: derrrick.com)
So your server will have to generate and respond with this page, filling in some.data.here, anytime http://yoursite.com/hosted-redirect/some.data.here is requested.
A lightweight node app could do this with a single file.
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.