No support for Google Drive, OneDrive or Dropbox or other cloud app? #342
Comments
|
There are several reasons why cloud code is not directly integrated into KeePassDX :
I've been thinking of creating another file manager application for this proprietary cloud API but I have to previously finish KeePassDX. https://github.com/Kunzisoft/KeePassDX/wiki/File-Manager-and-Sync |
|
@J-Jamet |
|
@Riajyuu Yes and no, not necessarily. It depends on the needs of each user. I personally created KeePass DX because the technical, functional and code requirements of other applications did not meet my expectations. So I realize this application according to my beliefs in the field of free software and using the technical choices that I learned during my studies. |
|
@J-Jamet OK. One more question:
Why & how? I don't think keepass database has any problem when being transferred even over HTTP. |
|
This is the principle of encapsulation. In software architecture, the software must be created to solve a single main problem. Recovering and sending files over the network has nothing to do with a password manager (In my opinion, let me explain). To compare with other software. It's like LibreOffice, it does not connect to the internet. To share a text file with a team, we include the file in a shared folder, or we use another FTP service or the synchronization with another application. It's the same with KeePass DX. If we start to integrate elements related to file sync by third party protocols, we will have to manage all the protocols and sync API in the main app. Maintainability is also a big problem in this case, for each transfer protocol or integrated API, we must update the entire application and go through the validation workflow. This is the purpose of a separate file manager application to do these actions (GDrive app, webdav app, or something else) . If your default file manager is not appropriate to your need, simply download one who do what you want. It is also possible to create a file manager connected with plugins for each synchronization protocol. (I have this project in mind but I must already release a final version of KeePass DX.) So, KeePass DX doesn't directly manage the files but interacts with the content provider https://developer.android.com/guide/topics/providers/content-providers of a file manager application in your device (by default an app with the name "File"). By using a content provider, there is no need for internet access. The app sees the elements that it just needs, no more, no less. If you see Google Drive during your file selection, it's an integrated file manager app and KeePass DX accesses files by the content provider of this app (with the Storage Access Framework https://developer.android.com/guide/topics/providers/document-provider ) of your file manager. Each tool does what it needs to do, which is much better for security and interoperability. In the case of Dropbox, the dropbox app seems to not support the Storage Access Framework implementation #90 used by the content provider. But it's the fault of dropbox. To alleviate this problem, as I said above, it is possible to create a separate file manager application to handle particular cases. |
|
I had tested kpdx with nextcloud sync — not practical... Proprietary file-access maybe like onedrive or Dropbox shouldn't be supported. |
|
If you install OneDrive in your Android you are able to open a KeePass DB in OneDrive, just not create a new one through the app. Not sure why. |
For me, the problem is the event that triggers the synchronization of the file of your external manager. The synchronization of your manager should be automatic if the stream of the file used in KeePassDX is written and closed or if another specific event is recovered (a broadcast for example). In this case, what matters is not the transport protocol but only the events which indicate that a file has been modified. |
@LAGonauta Simply because this manager ignores requests to open document from Android (Intent ACTION_OPEN_DOCUMENT) because it is not implemented. (See wiki) |
|
I have successfully opened and stored a keepass database in KeePassDX via OneDrive. First I couldn't save (or save didn't upload). But after I've marked the file in the OneDrive app as "offline" and enabled synchronizing offline files via wifi + mobile then the database was uploaded after I've changed it in KeePassDX. |
|
After a while KeePassDX said the file does not exist anymore. I assume OneDrive has revoked the access. I had to open it again via FileManager and OneDrive app. But the settings got lost (Biometric unlocking and my keyfile location). Can KeePassDX remember those? |
KeePassDX keeps URI links in memory for biometric recognition and associated settings. If the link is changed by the file manager, KeePassDX cannot link the new URI to an old one since it is simply not the same. It's like changing the URL of a website. If you specify specific options for this website in your browser, when you change URLs, they are no longer the same options specifically specified in the previous site. |
|
@J-Jamet never mind. It doesn't happen so often. |
|
I understand the author's obsession of keeping this excellent app clean. Though, I still got to say I vote for the support for standard open protocal such as ftp, webdav. I'm a half tech guy, just between the amateur geek and normal dumb users. I can handle the sync problem using Syncthing or other tools. But, a stone is always in my throat about KeepassDX, that is I can't introduce KeepassDX to my friends. My friends are all common people, not experts with phones or computers, they just the common people, not geeks. Common people all have troubles of forgetting passwords. I really want to recommand them a excellently beautiful, easy to use, convinient, clean, free and secure password manager, since Keepass2Android's UI and translation is not good, KeepassDX seems to be the only one password manager good enough. But the lethal problem of introducing KeepassDX to my friends is that: KeepassDX can't backup the database to remote storage. If, on a single chance, the user's phone got damaged, lost, their password will lost forever. You may say, you got to backup your database, man? Yeah, I know backup of course, but how about common folks? How much is the percentage that common people know and do the backup? It is a really low percentage! ! ! I don't think KeepassDX is only for geeks, the author also have the desire to provide a clean and pure experience to as many people as possible. But for now, KeepassDX can't accomplish this goal: Put password in it, set once, secure for after. The principal of keeping data safe requires at least one copy of the important data must be in a remote storage. If KeepassDX can't do that, the database for KeepassDX users are not secured properly. Even if a part of KeepassDX users backup manually using other apps, still, a big group of KeepassDX user's database are not secured. I don't count on KeepassDX introducing Dropbox Api or GDrive Api or Onedrive Api, I don't like them either. @J-Jamet Introducing open protocals (ftp, webdav...) do introduce the netword access permissions, but it won't contaminate the purity of KeepassDX. On the contrary, if KeepassDX can't make a backup on a remote storage by itself, The Kee in KeepassDX is not qualified since the Keepass means keep password for users and KeepassDX can't keep the database safe following 3-2-1 backup rule. I have a vision:
I wish the vision could come true oneday, or I still got to worry if my backup program is still running everyday. |
|
@HaujetZhao at least for OneDrive I can say (as reported above) KeePassDX works good together with the OneDrive App (which you should have installed anyway when using this service). |
|
KeePassDX is only a file editor, what you want is a file manager that does what you say. At the moment, it's just that none of the file managers you use meet your constraints with Webdav. The solution for this is to create a new WebDAV file manager dedicated app which offers with its content provider the correct synchronization elements to KeePassDX. If the problem is the lack of knowledge of the users, then they must be trained, with a presentation of the operation and animations that explain the concept. I understand that a lot of people are tempted because all other file managers offer the all built-in method. But I specifically created KeePassDX to separate these elements. Today it just lacks the second good application that could work plugin-based (to add the cloud APIs that everyone wants) and in fact, there are good foundations for creating it (already existing open source apps). |
So I understand it now. KeepassDX is focus on editing keepass database. I actually got another idea, which won't need the internet permission, while making KeepassDX accord with the 3-2-1 data safety rule. When users opens KeepassDX, it opens a keepass database from a certain URI, right? The weak point is that, that single file might be damaged, lost, causing data lost. That's why we need a remote storage path. But people also don't like backup manually. Since KeepassDX can get URI from other content provider, I think it will be no conceptual problem binding multi backup URI address to one existing local keepass database. So, that's the basic concept: User create or open a local keepass database, which is the main database. Users can also bind single or multi backup address to the main database in KeepassDX. All the backup address are URIs provides by content providers, such as some file manager, or OneDrive app. The read and write process are applied to the main database, but KeepassDX updates all the backup URIs in certain circumstance. Since the remote storage URIs can be provided by the content provider, KeepassDX can periods create remote backup of local database. The failure of backup process won't cause local database damage, maybe it's just the content provider is not running in the background, using a toast to alert user to check or update the backup URI is enough. That's it, one database, multi URIs, no Internet permissions. Seems to be a perfect solution. |
|
@HaujetZhao for Backup there is already a feature request #704 |
Actually they are pretty not the same. The #704 means to create backup version files before saving in prevent of writing error, and it requires KeepassDX to have built-in file manager so that it can create a new backup file. But the backup I mentioned above is more like sync (single direction sync), it doesn't require KeepassDX to create a new backup file, it just need user to provide one or more (remote) URIs and overwrite them all after saving in prevent of device lost. So this don't need KeepassDX to introduce a built-in file manager. Without introducing a new component, the development will be way more easier. |
I answered in your new issue but clearly no! The development will not be easier at all. You should not be afraid of new projects (external tool). Here it is not just two files, they are pipelines. Concretely, KeePassDX has data streams as input and copying streams is not at all easy depending on the state of these streams.The solution you propose to link two streams coming from different URIs requires to synchronize data (same data in two steams else error), to implement buffers, to verify that the access and the metadata are the same for the two streams, and that the write access is guaranteed. In addition, you have to manage the interface to know which URIs to link, which implies new elements to manage in the internal database of the application, new user screens, etc ... Or simply make a copy of files with an external tool. (Copying unchanging data with only one input and one output is very easy). |
In the diagram of the 3-2-1 backup rule, KeePassDX is not a storage actor, it is up to you to implement this storage part according to your needs. The easiest way is to retrieve the file stream closing event when the data has been sent to start the backup routines. |
You are right, saving the old version as backup versus saving the same version in a backup location. I mentioned it because the other ticket might be more related than this one. But I now saw you already opened a specific issue for your new idea. |
|
Against this one, the idea behind KeePass was to keep your data locally on your machines and not on some corporate companies' privacy invasive server. |
|
Against this one, too. Respect the dev, please keeping the faith of software development. |
|
I haven't yet found a easy sync solution for desktop yet but this works great for syncing database file to google drive in my android device - https://play.google.com/store/apps/details?id=com.ttxapps.drivesync . It even has auto sync option but i have it kept it off to save battery , i just prefer to manually trigger sync with a single click affect my database file has been updated locally |
|
If there's a lack of synchronization when the .kdbx file is changed on one source while you're using the other then that's really the definition of, "doesn't work".
|
Synchronization is your job, not the job of KeePassDX. I am sure you possess the very basic tech literacy needed to open KeePassDX and select the database file that has been synchronized by OneDrive, Dropbox, or what-have-you in the file manager. Try it, it's not hard at all. |
I agree with your general sentiment (different tools for different jobs), but I just had KeepassDX in combination with Onedrive destroy my database files. I tested this with 2 different phones and 2 different databases. KeepassXC now says: KeepassDX says: So for me, the question is not really wether or not there is in-built onedrive support (which it really shouldn't have imho), but more importantly, if the interaction with onedrive works at all. Can anyone shed some light here? |
|
There's an explanation for that : The stream of the file provider is interrupted (for some reason, depending of the app) during a file save. Obviously if the stream is interrupted, not all data is saved and the file becomes corrupted. It's like if you upload a file to a server and the server that provides the connection breaks it during the upload (here the application breaks the stream of the URI). I can do all the efforts I want in KeePassDX, I can't prevent this break of the provider. It is up to the app provider that provides the file to manage a cache to avoid this kind of case and not break a link while data is in transit. Clouds and applications want us to integrate their API because their application doesn't handle this kind of case. My point of view for the creation of a workaround file manager/provider app is here : #840 (comment) Otherwise in the meantime, you can save your file locally and upload it manually to your favorite Cloud application to avoid a link break. It is of course recommended to always make regular backups. https://github.com/Kunzisoft/KeePassDX/wiki/Backup |
|
Thanks for taking the time to explanation, I really appreciate it and I'm beginning to understand a little.. To get this straight, you chose to use the ContentProvider API instead of "regular" file operations, presumably to simplify your code and still be compatible to ContentProvider-only storage apps? However, for some reason the OneDrive provider is broken on file updates? Wouldn't that mean it's broken for every client that wants to update a file like KeepassDX? Is there no IOException or similar that can be handled (maybe with a rollback?). I'm struggling to understand that point still. |
|
SAF and Content Provider way is the regular way in Android ecosystem : https://developer.android.com/training/secure-file-sharing Access to the system file tree is very restricted and requires special permissions. In most cases, the methods provided by Android are symbolic or emulated links, only dedicated applications like file managers have access to a part of the tree (and in a restricted way). And yes, using the normal methods of accessing files in the Android documentation does not require additional permissions or rights
Theoretically yes, but in reality I do not know I do not use this app. I advise you to simply test One Drive with other client apps that use SAF and you will see the result. The thing I know is that many users have already reported to me that the same URI is sometimes used to open another file in the system. This means that the file provider of One Drive is pointing the URI reference to another file at some point. Which is extremely dangerous so I have no illusions about the rest of their code. #1118 (After that it would be better to look at their source code, you can always ask, haha)
If there are any, I already capture them and an error is displayed indicating an error in saving the file in KeePassDX. If there is no error displayed, it means that there is no exception, so theoretically there is no error in saving the provider's URI stream. (This is if you trust the content provider, which is implicitly the case for the user if he has installed the file manager application he wants.) This is just a theory, but I think there is a sync or cache problem in One Drive for whatever reason, the URI stream is break and the errors are not thrown. KeePassDX and the user thinks the save went well, tries to reopen the file that is corrupted and blames KeePassDX (I get a lot of emails and I waste my time explaining each time, that really tires me out). I make sure that the save code always runs smoothly and without problems, and everyone can see how it works. I am human and I am of course open to improvements. Anyone can check the code and propose technically and in detail improvements to the open code in KeePassDX. ;) |
|
Now that the merge is fully implemented, I close this issue. Google Drive : Kunzisoft/FileSync#4 |
|
All tickets are "closed", but the issues are still there and not resolved. Incl. the Nextcloud one. Yes, I can sync the file using Nextcloud and open the file using KeePassDX. However, the file link seems to get broken every often causing "Permission denied" because the file is getting revoked. See indeed the wiki page: https://github.com/Kunzisoft/KeePassDX/wiki/File-Manager-and-Sync#file-access-revocation KeePassDX can fix this if they allow integration of those Cloud apps (using their APIs) within KeePassDX, creating a native solution. |
#342 (comment) |
But you even closed the NextCloud issue and that hasn't been resolved, and I think that's the point. Most of the people commenting here never even cared about dropbox or onecloud or Box or gdrive - we chose KeePassDX and most also KeePassXC and we use and trust FOSS - not those privacy disrespecting, data mining, legacy monolithic silos. I haven't had problems with SyncThing but want to use NextCloud or Peergos and want absolutely nothing do to with google or Microsoft or any other privacy mining company. So after all this time, you've got a file syncing app (presumably at F-Droid) that syncs KeePassDX with corporate silos that I gather very few people using KeePassDX (Because it's FOSS) are even remotely interested in, while all the FOSSies here that chose KeePassDX still, after more than three years going round and round here, still do not have any viable solution involving a privacy respecting FOSS Solution like NextCloud or ownCloud? Oh man, I feel like we've been looking for a very simple solution that is FOSS and trustworthy that will never come, and that maybe that whole concept of using privacy respecting FOSS only has been completely ignored all this time! I don't mean to come off as sounding disrespectful, and I've donated in three past. I appreciate your efforts and commitment to open source, but people have been telling you over and over - many of us use degoogled phones, have no Microsoft accounts, will not consider them as legitimate solutions since they violate the public trust by deliberate design and then you make those silos the priority after almost 4 years of folks asking over and over and over again for a NextCloud sync... And then you close the issue because we can now sync with Microsoft or Google. As if that even counts to many people that have commented on these issues over there years. No thank you. I really don't care HOW you choose to implement a NextCloud sync. I care that nothing has been achieved in well over three years - there is no syncing solution at this time - dropbox and gdrive and onecloud or Box don't even count - they don't even exist in many people's universe. We have no sync solution for KeePassDX. |
|
The Nextcloud issue is here : Kunzisoft/FileSync#11 I didn't close the issue because there are other closed source solutions, I just closed it because NO synchronization code will be included in KeePassDX because the application IS and WILL BE only a KeePass file editor without internet permission. I've written about it all the time, I've always been clear on the subject and how the application uses the content provider of the synchronization applications. Here is the NextCloud synchronization application, on F-Droid! : https://f-droid.org/en/packages/com.nextcloud.client/ A workaround for link loss and file conflicts will be provided in the FileSync app but this project is only conceptualized and not yet coded. Again, I prioritize projects and work on my own time and I don't have four arms. https://github.com/Kunzisoft/KeePassDX/wiki/File-Manager-and-Sync I wrote a very detailed wiki on the subject. Note : Thank you for the donations, but where did you hear these rumors? |
|
Oh okay, great! You had talked about it a year or two back because you said there wasn't anyone else that had made such a file manger to replace the Google one that won't work with anything but the Google infra. I'll go and download your fille sync manager and start testing on NextCloud with KeePassDX and KeePassXC. If everything works out I'll be able to start switching some folks over from VaultWarden in a couple of weeks, so they can use it with their existing NextCloud systems. Thanks so much! I thought you were saying that your filesync manager only worked with Google, Microsoft, and other proprietary silos, and since the regular NextCloud file sync when tested caused data loss in the kdbx files it would never work. Thanks again! |
I absolutely never said that, any program can basically be updated so of course any app can work over time. 😵💫 |
That "file sync manager" has only 1 commit and is empty: https://github.com/Kunzisoft/FileSync |
|
@melroyvandenberg Why are you spamming when I have already replied to your comment on many threads... (#1089 (reply in thread)) The FileSync project is also designed to discuss synchronization. Since reopening this thread on KeePassDX will not change the way it works, please continue the discussion here : https://github.com/Kunzisoft/FileSync/discussions/landing. All projects have started at one time or another, nothing prevents you from being an actor of the solution you want to implement, any help is welcome. |
J-Jamet
changed the title
Add Web login support for Cloud services like OneDrive and Dropbox. I saw that I could use google drive, but I am working on getting away from using google software as much as possible.
KeepPass2Android isna good example of how this is done and it allows for one cloud saved keyfile to sync multiple password managers across several devices.
The text was updated successfully, but these errors were encountered: