Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Apple-mobile-web-app-capable meta tag breaks login persistence on iOS Safari #1792
What were you doing?
Opening Octoprint via iOS Safari, using a "home screen icon" created by Safari.
What did you expect to happen?
After starting Safari and logging in once, I expect Octoprint (via cookie) to remember the login for the next session.
What happened instead?
The Octoprint login does not persist across sessions when Safari on iOS is launched from a "home screen icon."
There are two ways to start Safari and access Octoprint.
Method-1 (works OK): Starting Safari from it's own icon, then navigating to Octoprint via Favorite or by typing in the URL. Using this method, the Octoprint login always persists across sessions just as it should.
Method-2 (does not work OK): Starting Safari from a "Home Screen Icon". Using this method, the Octoprint login does not persist and the user must login for every session. (A home screen icon is created by launching Safari normally, navigating to Octoprint, logging in, then using Safari's "Add to Home Screen" function. This creates a home screen icon that launches Safari and automatically navigates to the Octoprint instance.)
This behavior is caused by the following metatag in template index.jinja2:
If this meta value is changed to "no" (or is not present at all), Method-2 works exactly like Method-1. The home screen icon created by Safari is not classified as a "Web App", and therefore will open a normal Safari session that supports cookies. Logins persist across sessions opened from the home screen icon exactly as they do from a normal Safari session.
Since Octoprint relies upon a cookie for persistent login, I believe it should NOT specify "yes" for "apple-mobile-web-app-capable". It is not fully functional when launched as a Web App, because Octoprint uses a cookie, and cookies are not supported when Safari sessions launched as a Web App.
I suggest changing this value to "no" in future builds. The alternative would be to use "html5 local storage", but that would require additional code to detect/use html5 local storage to preserve a logon token, and the benefits of running Octoprint as a "Web App" as opposed to a normal Safari session are limited.
Branch & Commit or Version of OctoPrint
Printer model & used firmware incl. version
Does not matter. (Lulzbot Mini, Marlin 188.8.131.52)
Browser and Version of Browser, Operating System running Browser
Safari on iOS 10.2.1. However, I believe the behavior mentioned has been the same since iOS 7.
Link to octoprint.log
Link to contents of terminal tab or serial.log
Screenshot(s) showing the problem:
I have read the FAQ.
Thanks for reporting this. I took a look and that line was introduced as part of a (mislabeled) commit that fixed some weird behaviour on (I think) mobile Safari with regards to the Settings dialog not rendering properly, making it unusable.
The problem is that right now I cannot remember if that specific line actually was part of the solution for the above problem or more a case of a left-over from experiments in trying to get the problem under control.
In any case, I fear in order to avoid breaking the settings dialog again, some tests on an Apple device are in order. I'll try to get an iPad in my hands.
I did some testing of the Settings dialogs on my iPad-Air-2 and iPhone 6s (both iOS 10.2.1). On each one, I compared rendering to Chrome/Windows to make sure all elements were displayed. Then I tested to ensure that I could interact with all fields and controls. This included Settings dialogs for the Plugins I use (CuraEngine, Email Notifier, Navbar Temperature, Print History, Custom Control Editor). The only problem I encountered was the inability to "drag and drop" controls in Custom Control Editor; however, this behavior has always existed on iOS Safari no matter how it is launched.
I compared the Settings dialog operation on iPhone, with and without the meta tag. I found no functional difference aside from login persistence. The only visual difference was the presence of the address bar. In both cases, it was a challenge to use in portrait mode due to the left/right frames on the iPhone's narrow screen. Much easier in landscape. But again, no functional difference based on the meta tag, other than login persistence.
If I can help with any other specific tests on iPad/iPhone (with iOS 10.2.1), let me know.
I would be good if someone could test with other versions -- at least iOS 8/9, since there are still a fair number of devices using those. As well, it should be tested on Mac Safari, but to my understanding the meta tag only affects mobile (iOS) devices. I don't have a Mac, nor any iOS 8/9 devices, so I am unable to help with those.
Thank you for looking into it!
I am not a dev. Maybe this would help?
That thread is from 2011, which was late iOS4 or early iOS5, and a lot has changed since then. Here is a more up-to-date thread from the same site, which discusses the evolution of how "web apps" treat cookies:
Since iOS 7, it is my understanding that all cookies are tossed at session end when Safari is started as a "web app", regardless of any lifetime setting. The only persistent storage I have seen mentioned for "web apps" is html5 local storage, or by using strings within the URL itself.
It is also my understanding that Octoprint uses the Flask framework to manage sessions (including login). Again, not an expert on Flask... But searching and reading multiple threads leads me to believe Flask uses only session cookies. Expanding the lifetime of a session cookie will not work with a "web app" since it throws away session cookies at end of session. I don't see any reference to Flask having support for html5 local storage.
I question whether the value provided by being a "web app" (elimination of the address bar) is of sufficient benefit to warrant further development to implement an alternate method to track and maintain login sessions. Simply removing the meta tag, or changing its value to "no", allows proper login persistence whether the Safari session is started normally or from a "home screen icon".
I don't think that merits a full blown change in the session handling and considering that apparently the change was not related to the rendering issues of the Settings dialog after all (at least I could not reproduce the issues I had back when I pushed the commit that included those meta tags even without them), I've simply removed that header again, and also the status bar and the generic non-apple one. It doesn't make sense to keep them in there set to "no" considering that this is the default value if absent anyhow.
So that is now fixed on the
A final note though.... This is from the official documentation by Apple about that meta header:
No word about changes in cookie handling there - gotta love undocumented side effects.
Thank you, Gina!
I did a pretty thorough search of Apple's documentation, looking for some other reference to changed cookie behavior with that meta tag. I found nothing aside from the info you quoted above. There are multiple mentions of the terms "web application" and "standalone mode", but searching for those did not turn up any additional documentation regarding cookie behavior.
That leaves me wondering if the behavior is intended or an Apple oversight (bug). I did find reference to "web applications" being sandboxed, similar to how actual iOS apps are sandboxed. So it is possible the intended behavior was just to keep a "web application's" cookies separate from all other cookies (both those for other "web applications", and those from normally-launched Safari sessions). That would actually make a lot of sense, but is definitely not how it is implemented.
Thank you for the update!
Working fine for me since the fix in 1.3.2, I use it near daily and just checked (I'm currently on 1.3.6 also).
What version iOS? When you start from a "Home Screen Icon", are you getting an address bar at the top?
Also be aware that a “home screen icon” that was created while viewing a page from 1.3.1 or earlier will still exhibit the problem. Any icons created before 1.3.2 need to be deleted and then re-created while viewing a page rendered by 1.3.2 or later.
Nevermind, reappeared after a couple hours. I'm running Android 8.0.0 with EMUI 8.0.0, Octoprint 1.3.7 on OctoPi 0.14.0, and Chrome 65.0.3325.109.
I know nothing of Android... But part of the "fix" on iOS was to delete the old home screen icon, and create a new one AFTER upgrading Octoprint to 1.3.2. So if you are using a "home screen icon" created when using an earlier version, try deleting it and creating a new one.
Note that the problem in this (closed) issue was specific to iOS -- and a meta-tag specifically intended for and acted upon by Apple iOS. So even if your symptoms are the same, the issue is different. I therefore recommend you open a new issue, specific to Android, and provide all the information requested in the new issues template. That will give your problem proper visibility and allow for it to be investigated.
That's what I planned to do. I'll create a new issue.…
On Wed, Apr 11, 2018, 17:34 ScottWell1 ***@***.***> wrote: @theaquarium <https://github.com/theaquarium> - I know nothing of Android... But part of the "fix" on iOS was to delete the old home screen icon, and create a new one AFTER upgrading Octoprint to 1.3.2. So if you are using a "home screen icon" created when using an earlier version, try deleting it and creating a new one. Note that the problem in this (closed) issue was specific to iOS -- and a meta-tag specifically intended for and acted upon by Apple iOS. So even if your symptoms are the same, the issue is different. I therefore recommend you open a new issue, specific to Android, and provide all the information requested in the new issues template. That will give your problem proper visibility and allow for it to be investigated. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1792 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZTMJUfhapOX1H-VC7z5raYgid5BfBIRks5tnnbYgaJpZM4MMKu3> .