-
Notifications
You must be signed in to change notification settings - Fork 42
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
[FR] customize the address to allow connection to a remote Buttercup Desktop app #491
Comments
With the previous V2, this flexibility was not needed since the extension was mostly managing its own connections to the different vaults, as do the Desktop app and the Mobile app. |
Hello. I see what you're getting at, and appreciate the change in workflow being tedious. I don't maybe think that this would be the best way for Buttercup to offer remote connectivity, however, concerning the browser extension. I'll explain why. The extension is meant to be, in my eyes (after v2), a very lightweight helper that extends login assistance to the browser from the desktop app. In the same way, the desktop app was not intended to become a server. Both overlap a little but I'd prefer that this fact is more invisible than it is now. Imo there's 2 ways that this could/should work:
There is a slight possibility that we add connectivity via the server directly to the extension, but this could violate our security expectations of the server so I'm not sure yet. This all being said, I'm potentially ok with having the ability to customise the desktop applications host name and port, as there are some valid use cases for it:
This is more of an architectural question than a technical one- and it has to suit what Buttercup is to be to the public. EDIT: regarding your local+remote dilemma, I'd suggest that this wouldn't be necessary if we keep the desktop application as the point of contact. It's meant to be the proxy, of sorts, for the addon. |
local+remote dilemma: if the desktop app is used as a proxy, then I need to find a way for our shared vault to be accessible by each of our team members. Google Drive is not an option for now, and Buttercup server has not been released yet. So I'll see what I can do about a WebDAV server. We have a an old QNAP NAS that could maybe be used for this purpose, if it supports it. We also have an old laptop that could be repurposed. |
Would there be a need for customizable fields in both the Desktop app and the extension in this scenario? For the Desktop app to set a different port and for the extension to point to a hostname and port customized values? |
Hi,
Since V3 now depends on Buttercup Desktop app and because Google screwed us a bit with its Google Drive default scope change (only files created by the app are available), we lost an import feature that I'm trying to bring back: shared vaults.
We were sharing a single vault through Google Drive between the our team for some common accesses, Google Drive was allowing us to share the file within a Group and Buttercup was able to connect to it once a user identified itself through it Google account.
I tried using Microsoft OneDrive to access our shared vault, but OneDrive will create a new file for each machine that have the vault opened when saving new entries. So, this is not an alternative.
So I'm thinking about using a single machine as a common access point to our shared vault, where Buttercup Desktop would play the role of a server. But for that to work, the extension would need to have a way to request a connection to a remote machine that is not the localhost.
However, if I go further in the reflexion, it would be preferable to have the extension able to connect both locally and remotely at the same time:
This way, users who also use Buttercup for personal password management would still be able to do so.
So the feature is not as simple as adding a custom field under Settings > Advanced settings (which would already be more flexible than the current situation). It is a way to customize the connection to be established itself before adding a vault and to establish more than one connection.
The text was updated successfully, but these errors were encountered: