Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apple-mobile-web-app-capable meta tag breaks login persistence on iOS Safari #1792

Closed
ScottWell1 opened this issue Feb 25, 2017 · 18 comments

Comments

Projects
None yet
5 participants
@ScottWell1
Copy link

commented Feb 25, 2017

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:
<meta name="apple-mobile-web-app-capable" content="yes">

When Safari sees that line, the home screen icon it creates is classified as a "Web App". Among other differences, when Safari is opened as a "Web App" there is no Cookie support!. This is why the Octoprint login does not persist; there is no cookie storage. Web sites which need to use cookies should NOT use the "apple-mobile-web-app-capable" with a value of "yes".

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

Stable 1.3.1

Printer model & used firmware incl. version

Does not matter. (Lulzbot Mini, Marlin 1.1.0.11)

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

NA

Link to contents of terminal tab or serial.log

NA

Link to contents of Javascript console in the browser

NA

Screenshot(s) showing the problem:

NA

I have read the FAQ.
Yes.

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 1, 2017

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.

@ScottWell1

This comment has been minimized.

Copy link
Author

commented Mar 1, 2017

The only visual difference when launching as a "web app" is that the address bar (and page tabs on iPad) are eliminated. That provides slightly more real estate for the web page itself, which might be advantageous on smaller (i.e., iPhone) screens. But as mentioned above, launching as a "web app" also breaks the login persistence because "web apps" cannot use cookies and reinitialize fully on every launch.

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!

@lixxbox

This comment has been minimized.

Copy link

commented Mar 4, 2017

@ScottWell1

This comment has been minimized.

Copy link
Author

commented Mar 4, 2017

I am not a dev. Maybe this would help?
http://stackoverflow.com/questions/7077518/ios-full-screen-web-app-drops-cookies

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:
http://stackoverflow.com/questions/21109615/ios7-safari-saving-to-home-screen-and-persist-token

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".

@ScottWell1 ScottWell1 closed this Mar 4, 2017

@ScottWell1 ScottWell1 reopened this Mar 4, 2017

@ScottWell1

This comment has been minimized.

Copy link
Author

commented Mar 4, 2017

Ooops.. Accidentally hit "close" at last comment. Reopened! :-)

foosel added a commit that referenced this issue Mar 6, 2017

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 6, 2017

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 maintenance branch and soon also the devel branch and will be part of the 1.3.2 release.

A final note though.... This is from the official documentation by Apple about that meta header:

apple-mobile-web-app-capable

Sets whether a web application runs in full-screen mode.

Syntax

<meta name="apple-mobile-web-app-capable" content="yes">

Discussion

If content is set to yes, the web application runs in full-screen mode; otherwise, it does not. The default behavior is to use Safari to display web content.
You can determine whether a webpage is displayed in full-screen mode using the window.navigator.standalone read-only Boolean JavaScript property.

Availability

Available for iOS.

Support Level

Apple extension.

No word about changes in cookie handling there - gotta love undocumented side effects.

@foosel foosel added the status:solved label Mar 6, 2017

@foosel foosel added this to the 1.3.2 milestone Mar 6, 2017

@ScottWell1

This comment has been minimized.

Copy link
Author

commented Mar 6, 2017

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.

Either way, whether intended or an Apple bug, the current behavior associated with that meta tag is incompatible with web sites that use cookies across sessions. I will keep an eye on future versions of iOS and bring the issue up again if/when the behavior changes.

Thank you for the update!

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 16, 2017

1.3.2 was just released.

@foosel foosel closed this Mar 16, 2017

@LazaroFilm

This comment has been minimized.

Copy link

commented Feb 20, 2018

So this issue was closed without being fixed?

@foosel

This comment has been minimized.

Copy link
Owner

commented Feb 20, 2018

@LazaroFilm

So that is now fixed on the maintenance branch and soon also the devel branch and will be part of the 1.3.2 release.

#1792 (comment)

@LazaroFilm

This comment has been minimized.

Copy link

commented Feb 20, 2018

I'm running 1.3.6 and still have the same issue...

@ScottWell1

This comment has been minimized.

Copy link
Author

commented Feb 21, 2018

@LazaroFilm -

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.

@theaquarium

This comment has been minimized.

Copy link

commented Apr 10, 2018

This same problem persists on Android

@foosel

This comment has been minimized.

Copy link
Owner

commented Apr 11, 2018

More details please. What OS version, what browser, what version of OctoPrint, ...

I can't read minds.

@theaquarium

This comment has been minimized.

Copy link

commented Apr 11, 2018

Hmm, I just updated to 1.3.7 from 1.3.6 and the issue is gone.

@theaquarium

This comment has been minimized.

Copy link

commented Apr 11, 2018

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.
When I use Octoprint through the browser, my credentials are saved when I select remember me. When using Octoprint through the homescreen with the "Add to Home Screen" Dialog, credentials are not saved.

@ScottWell1

This comment has been minimized.

Copy link
Author

commented Apr 11, 2018

@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.

@theaquarium

This comment has been minimized.

Copy link

commented Apr 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.