Since iOS 11 one of our web-apps has been acting up, but only when added to the Home Screen as an app.
It allows for offline viewing of documents, cached using an ApplicationCache manifest, for the users selected language.
The problem is arising when users are choosing a new language.
We're persisting the language token (ie, en_GB, or de_DE) to a cookie using document.cookie, we then tell the appcache to look for updates. The server looks at the language token in the cookie and sends down a language-specific cache.manifest file.
This is the JS when the user changes their language
function setLanguage(chosenLanguage) {
//...
this.setCookie("language", chosenLanguage, 10);
window.applicationCache.update();
}
this.setCookie uses document.cookie to change the cookie value, with the expiry time in days.
This works fine on desktop, and on mobile, even on iOS 11 safari.
Except in Home Screen App mode on iOS 11.
By setting a unique ID each time the cookie updates, we can look in the Web Inspector console to check the unique ids set at each point and compare them to what's being recieved by the server.
We've discovered that the Home Screen app is sending up the the cookie that was created in Safari. Not the one that was created using document.cookie in the Home screen App. That cookie is never sent up with any of our requests.
Not only that, but if we go back into the Safari browser version and change the language, then swap back to the Home Screen App, it sends up the updated safari cookie with the new language, but reading from document.cookie still shows the data we previously set in the app.
What I want to know is: Has anyone else had this problem and does anyone know a fix for it?
Related
So the usual flow for magic link is:
User clicks on the link in their email (e.g. www.domain.com/auth/:token)
Page is opened in the email’s in-app browser.
Token is stored in the in-app browser’s local storage and token is removed from the URL (either by redirection or some other method).
User is logged-in (in the in-app browser).
The problem happens if the user then clicks the “Open this app in Safari” (or another browser) in a mobile's in-app browser. The user will be logged-out since the local storage state is not carried over and the token was already removed from URL parameter. Unless the token is present as a query / parameter on every page URL which is unsecure and defeats the purpose of using local storage.
What is the best solution for this use case without providing a typical login flow (username/pw)? (Or is that the only way?) Seems like you cannot browse any app in iOS using a magic link via an actual browser app since the magic link will always come from your email app (and hence, will always be opened using the in-app browser).
To use a magic link in order to open your App from an anchor clicked into an email client, you need definitely to setup Universal Links.
That said, things are not always that simple. In some circumstances Universal Links won't work and will open directly into some in-app browsers instead opening your app, this occurs sometimes with the SafariViewController embedded into email clients as you noticed.
So what to do to make it work in all cases?
As you know an Universal Link should open your app if it is installed, but it should also open a fallback web-page in any other circumstances when your app cannot be opened. This is where you will make it bulletproof: on the fallback web-page make sure you put an obvious button with a "safety" second/backup Universal Link that will do the exact same action into your app.
It will work because if your Universal Link fails to open directly from the email client and opens a browser window by mistake, it will most probably open your app when triggered from the in-app browser fallback web-page.
At the end, you might want to focus and put an extra effort to setup a very nice design for your fallback web page, making it look like your app, to provide a good UX so that your users may not even notice that they went thru an extra-step…
I'm in the same boat with our webapp's passwordless login authentication. Did you end up using Universal Links to successfully overcome the issue?
We have link functionality in our web application that when clicked, browses to a page on our server that performs the following:
Tries to open the custom url to our ios application
If this fails, it redirects the user to our ios app store to download the app.
This actually all works perfectly well.
However, it creates a weird corner case, where after a user has done this and finished, if they come back sometime later and open their safari on the same phone, if our web link is still the active tab, it will redirect them again to our application.
The cause of this is fairly obvious, but we are struggling to come up with a solution for it. Is there any known to rectify this behavior, either through a different mechanism then I described for opening the application or through somehow killing the page simultaneously?
I am using the HttpContext.Current.Session.IsNewSession to decide on what page to show when my MVC4 application launches.
This works great on desktop, iOS safari.
However on iOS Chrome, every time I close the browser (actually close tabs and close the application from the task manager) and relaunch it the IsNewSession is always false.
I am guessing it uses the session cookie ASP.NET_SessionId to track this as there is a new cookie value when I close my desktop or safari.
However on iOS Chrome, when I close and relaunch the cookie has the old value - which I am guessing is the root of the issue.
So why does iOS/Chrome not clear my ASP.NET_SessionId cookie even though it should be a Session cookie and deleted when the browser is closed.
Thanks.
I suspect this is because of a design feature of many modern mobile operating systems whereby apps don't really close when you might think.
With desktop applications you have a lot more screen real estate and so it's easier to manage windows and multitask. So closing applications feels natural and necessary when you're done with it.
With mobile applications, however, there is more of a focus on the user being able to open and switch between applications seemlessly and so the concept of closing or minimising apps is abstracted away and taken care of by the operating system.
This means that when you close Chrome, it's not really closing (and may not close at all before you enter the app again). Therefore the session is never cleared.
If you force close the app then your function will work as expected.
There's no elegant work-around that I can think of for your problem. One idea is to store the time of last activity for the user and if it's greater than, for example, 5 minutes, then you can show them your startup page.
I have an application built using XPages' mobile controls. On an ipHone the application behaves as I would like in the standard Safari browser. When I take the url and add it to the Home Page as an icon and use the application from there every time an action I take invokes a native application (Maps, Contacts, Phone, attachment viewers etc.) when I switch back to my application I am immediately asked for my userid and password again. Is there a way to control the behavior to not lose the login credentials the same way that the standard Safari application seems to.
This is a limitation in iOS. If you save it to the home page like that it works, but it will NOT multi-task. That's the problem. So it doesn't remember where you were or anything like that.
As David mentions it starts all over again when you switch back.... The problem is not only the credentials - it is also all the information you may have entered or where you have navigated to in the "app".
This is why I am changing to another approach. I am starting to write apps as web-apps that run locally (i.e. cache the ressources and run on the cached versions of the JS-files, CSS and images). Then I implement a localstorage where you can track where in the app you are - and return to that place again. This way you do not need the authentication for running the app - only for synchronizing the information with the server. My approach is to save data locally and sync them to the server (as a sort of replication). This obviously gives more work - but it also gives a better user experience since you can run the "app" without being connected.
I have tried to control the caching locally using a cache.manifest file. This can be done, however, it is a pain. Therefore, I am now using Sencha Touch which really does this nicely.
/John
PS. I think you may be able to handle the login issue by using the XPage Dojo login custom control (http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=Xpages%20Dojo%20Login%20Custom%20Control) - however, it does not solve the issue with reloading the page...
It seems the secret to success here is NOT to tell Safari the XPage is capable of acting as a mobile web app. Add the following code inside for the XPage to ensure this is the case.
<xp:metaData
name="apple-mobile-web-app-capable"
content="no">
</xp:metaData>
Note: You can still provide an icon for the home screen, its just that icon will now act more like a bookmark with the Safari controls and (more importantly) you can switch between applications and when you return to Safari it will display your Xpages app just as you left it.
I've got (actually my employer has) a mobile website that enables Safari integration (for iPhones and iPads) - meaning that customers can bookmark it to their home screen and then it would behave as a standalone web app (no address bar, custom icon, start-up image etc).
It works all right except that one week ago (coincidentally soon after apple has released iOS 6.1.2) some of our customers (6 of them initially) complained that they no longer get the normal content but a '404 page' of a public wifi provider (The Cloud owned by Sky here in the UK). After a bit of investigation we've figured that at some point those customers connected to the Cloud wifi without actually logging in (it's one of those providers that would redirect you to a login page to enter your credentials, after which you can carry on browsing). The thing is that even after switching back to their private wifi or mobile data connection the application would display the Cloud's page.
This only happens (as far as I can tell) when the application is launched via the bookmark (I couldn't see this behavior when using it from safari).
What happens is that the customers would connect to the cloud wifi (without logging in), they would open the application at which point the router will issue a redirect response to their login page; the application would cache the login page and it will always display it whenever using the bookmark again. (I've performed a capture when this happens and there are no requests being made at start-up whatsoever).
Even weirder, in this situation, if removing the existing bookmark and adding a new one will show you the same cached page (with the whole operation being performed away from the Cloud). We've fixed this by adding a unique identifier to the URL each time we hit the bookmark screen (this indicates that the web apps' sandboxes are linked to the url, which is to be expected).
What we're trying to achieve is to have the application properly recovering after the customer has moved away from the Cloud. But there doesn't seem to be a straight forward way to do this.
Furthermore there's a level of inconsistency in all of this - most of the times when the flow is performed I will see a 404 page (a custom 404 page https://service.thecloud.net/service-platform), but sometimes I would be properly redirected to the login page, in which case the application would not break.
My assumption is that there is a weird race condition in the standalone web app application model causing the browser not to properly handle redirects (and actually caching 404 pages). I've raised a support incident with Apple (which eventually turned into a bug report) but it might take a while and I'm trying my best to figure out a workaround.
Any ideas, maybe someone has seen this before?
The issue is aggravated by the fact that I need to have a 5 minutes walk ever time I'm testing any fixes; I've tried creating simple test forms, but I wasn't able to reproduce the issue, where as with the full app I can do it pretty much every time.
Here's a summary of the steps to reproduce:
Via private wifi (or mobile data connection) add a bookmark to a website (I've managed to reproduce it with quite a couple of apps that support safari integration as described above)
Open the application to review the normal content
Connect to a Cloud hotspot and open the application from the bookmark (open-close it for a couple of times if you don't get the 404 right away)
Connect to the private wifi (or mobile data connection) and open the application via the bookmark -> you'll see the same 404 page again
In the end the fix was to add a unique query string parameter with the initial page request (pretty easy with the setup we already had, via the launcher page). I've filed a bug report with Apple which they've acknowledged by linking it to a previous item. Here's a post on the topic:
http://blog.onos.ro/ios-6.1.2-caching-issue