Bachsau

Yes, I was using the same Apple ID for Enpass that is configured in the system settings, and I would like to state that this wasn't in question if Enpass accessed the iCloud through the operating system's APIs, as it would obviously use that same connection without even asking for a login. "Sign-in with Apple" is not used by Enpass, so it can't be revoked. That single sign-in service is for third-party user accounts, not apps. If you meant to ask if the iCloud and the switch to allow Enpass to use the iCloud is enabled in system settings, the answer is yes.

In this case it was Enpass 6.8.4 from the Mac App Store on macOS 10.15.7 (older iMac). The Browser is Safari 15.6.1, but as I said, you normally don't need a browser login on macOS at all to access iCloud.

I already did but got either misunderstood or ignored. 1. I already described the problem with iCloud here, but you just gave me an FAQ link, which of course I already read, because I investigate on issues before posting. I also wrote about what I think is the root of the problem, but you don't seem to have read it. Other users on that threat also wrote that following the FAQ tip did not solve the problem. 2. Regarding my WebDAV problems, I opened three tickets (not at the same time). Two of them got deleted without notice. The third one, ECS-31081, got aknowledged after I complained on the forums. I'm still waiting for a fix. 3. Regarding the support, you already seem to be in that state of big companies, where a phalanx of supporters "protect" the developers from customers. The problem being that those supporters know nothing about the inner workings of the product. Developers should at least sometimes read the forums themselves, so they can learn about problems firsthand. The problem described in this thread (new entries overwritten with older ones) should not have happened at all. It is an obvious sign of bad software design. 4. In all Desktop versions, Categories and Tags are sometimes missing from the sidebar. This seems to happen mostly when startup takes longer than usual, so I guess it's a race condition. Enpass needs to be restarted for them to show up again. The iOS version sometimes displays wrong website icons on several entries after new items have been synced to the device. The correct icons re-appear after scrolling them out of screen and back. These are rather small errors, but they have existed for several versions now. I'm a coder myself, so I know what I'm talking about. You should stop developing new features for a while and focus on optimizations and bug fixing.

This doesn't work for long and I told you why. As I already said, Enpass is the only app with this problem. iCloud sessions do not expire for other apps or Enpass on iOS. If you would access the iCloud the same way on macOS as you do on iOS, this problem would not exist. Maybe the way you access the iCloud is the only way on Windows and Linux, but at least on macOS you should access it by means of the operating system.

The way Enpass connects to the iCloud on iOS is the right way to do it. The macOS version uses a different approach, which might allow you to set it up with a different account, but also causes the session timeout problem, because it's not the way it's meant to be done by Apple. Furthermore you shouldn't share accounts with your wife. Encourage her to get her own ones.

I think I will be going back to 1Password soon. Enpass is just a bundle of bugs. It has the better concept, but the developers obviously don't know what they're doing. iCloud sync is buggy, WebDAV is buggy, data gets lost. Support is bad, tickets get deleted, and there is no way for customers to talk to the developers directly.

Enpass is the only app with this problem. It is also the only app which creates its own session through a web browser. Why doesn't it use the operating system's APIs to access iCloud like every other app? This problem only exists because Enpass uses iCloud in a way it isn't meant to be used. Normally, if the Mac is properly connected with an Apple ID, applications don't need any additional authentication at all to access iCloud.

Hardware keys can never beat a good passphrase. They will either be cracked some day or be destroyed, resulting in data loss.

I just answered your followup questions via email. However, I really would like to know why my previous tickets were just deleted.

No, you don't. Just post your whole life publicly on the internet and be done with it. Until this happens. If you don't care about your privacy and security, noone can help you.

Why don't you display real, meaningful error messages instead of those cryptic numbers?

I'm crossposting this here because it's possible. Don't know why threads are allowed at this level when there is a sub-forum for everything.

It is a new and very annoying feature of macOS Monterey that Documents inside containers are displayed inside the real Documents folder. It doesn't really exist there, neither as a directory nor as a link. Finder just lies to you and displays it there, much like it still displays all the Applications in the "/Applications" folder, while many of them only exist in "/System/Applications". To answer your question: You can hide it by setting the "hidden" flag on the Documents directory of the container. Open a terminal and enter this command: chflags hidden ~/Library/Containers//in.sinew.Enpass-Desktop/Data/Documents This is not possible in the Mac App Store version. For no good reason, of course, and "~/Library/Containers//in.sinew.Enpass-Desktop/Data/Library/Application Support/Enpass/Documents" would have been a better choice for the default location. The same applies to all operating systems. On Linux the default location is "~/Documents/Enpass", which is also a terrible choice, because this is clearly application data. I moved it to "~/.local/share/Enpass/Documents". Edit: Why do I have to put two slashes between "Containers" and "in.sinew.enpass" to keep this crappy board system from replacing it with an "e"?

Since a few months I experience massiv problems with WebDAV and the support is actively ignoring my requests. I wrote about the following problem in two support tickets (ECS-30210 & ECS-30252). Both times I received acknowledgments from the Jira ticket system, and both tickets were actively deleted a few hours later without further notice! When I click the "View request" link and login to the support system, I'm told that the issue can not be found and doesn't exist. Maybe they are going to delete this topic as well, but I have to try. Now, the problem: Almost every other week sync stops working and I'm told that my password is wrong and I need to enter the new one. However, sometimes it just displays a numeric error code without further explaination. My password didn't change, and so far the only way to get it working again, was to restore the ~/Library/Containerse.sinew.Enpass-Desktop folder from a Time Machine backup. That always worked but is nothing I wanted to do forever, so I decided to disconnect all devices, remove the WebDAV contents and start again. But now, when I try to set up the connection again, I'm instantly told by Enpass that it could not connect to the specified WebDAV folder and that I should check my username and passwort, which are definitely correct! This only happens on MacOS. I also had iOS, Linux and Windows devices connected to the same WebDAV server and never encountered the problem on any of them. I tentatively identified that it has something to do with the WebDAV path containing a space, but this wasn't a problem when I initially set it up in March of this year. However, if I shorten the path up to the directory above the problematic part, it does connect, then instantly fails with error 906403, because that directory is read-only. I can do nothing about this suboptimal situation, because this is just how OpenXchange URLs look like. The full scheme is ""https://server.example/servlet/webdav.infostore/Userstore/Firstname Lastname/". I also tried encoding the space by typing %20 or +, but that didn't work either. In case of %20 the error code is 906409. This needs to be fixed and soon! PS: While the errors only happened on MacOS, re-setup seems impossible on any device now. At least the Linux version is able to write some kind of log file, but all I got was this: Info: [HTTP] Enabling VERIFY SSL PEER/HOST Info: [HTTP] Using AUTO Proxy detection Error: [configTeamVaultsSync] 120 ERROR in enabling sync for primary : local : true Info: [HTTP] Enabling VERIFY SSL PEER/HOST Info: [HTTP] Using AUTO Proxy detection Info: [HTTP] Enabling VERIFY SSL PEER/HOST Info: [HTTP] Using AUTO Proxy detection Info: [HTTP] Enabling VERIFY SSL PEER/HOST Info: [HTTP] Using AUTO Proxy detection Info: [HTTP] Enabling VERIFY SSL PEER/HOST Info: [HTTP] Using AUTO Proxy detection Info: [HTTP] Enabling VERIFY SSL PEER/HOST Info: [HTTP] Using AUTO Proxy detection Info: [HTTP] Enabling VERIFY SSL PEER/HOST Info: [HTTP] Using AUTO Proxy detection Not very informative... Definitely not what a good debug log should look like. No information about the HTTP requests that were sent and what they resulted in.

I can't believe this came from a team member. "%20" is the URL encoded representation of a space, not some weird escape sequence. The correct encondig of the URL above would be "davs://foo.bar/servlet/webdav.infostore/Userstore/Us%C3%89%C3%89%C3%89er%20Na%C3%89%C3%89%C3%89me" However, I found out that Enpass does neither require nor support pre-encoded URLs, not even "%20", which means you have to put "davs://foo.bar/servlet/webdav.infostore/Userstore/UsÉÉÉer NaÉÉÉme" to make it work.