-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add (secure) support for browser integration #259
Comments
Someone is creating a substitute for them both? I think RPC is still better than HTTP (but that autotype is definetly the best) |
I'm happy with either solution. Only someone has to do it. We don't have the resources to develop and maintain two browser plugins. And in the best case, you also want a standard that is compatible with other KeePass products. There is a lot of work attached to such a "simple" thing. |
I might have misread a comment. I am also happy with either solution. I imagine focussing on the standard would be best practice, having the browser plugins part external from the KPXC project. Or does that introduce (security) problems? |
Does autotype works under Wayland? |
Autotype doesn't work with wayland. |
Perhaps that needs to be a feature in wayland? I am not familiar with that project enough to know if that was specifically excluded. |
One goal of wayland is to sandbox applications and windows. |
Just as a side note I got a working non-global autotype for wayland, it sends keys through the linux user input system (uinput). However the user needs to configure it and switch windows manually... |
Wayland is really an unsolved problem. But you're welcome to create a pull request, so we can start finding an appropriate solution. |
@phoerious I will create a pull reqeust when the implementation is stable. https://github.com/rockihack/keepassx/tree/wayland-autotype |
I'll try it when I find the time. Thanks. |
I tried both keefox (keepassrpc) and passifox (keepasshttp), I think keefox / keepassRPC is ahead in term of integration, accessibility and functionality but might be harder to port to keepassxc. Keefox is providing an additional tab in keepass allowing to easily hide the entry from firefox, set priority override, define how to match and URL and add custom URL. |
We need a cross-browser solution, though. |
Perhaps KeePassXC could instead expose a WebSocket server (example), and serve password data over HTTPS to browser add-ons (implemented as WebSocket clients)? |
Just saw Native Messaging suggested as an alternative to an |
Cool idea but yikes, boost is the last dependency I want to add! |
@droidmonkey Which one requires Boost (WebSocket or Native Messaging)? Perhaps browser integration would be a separate package (there only for those that want it). |
Websocket server requires boost libraries which are basically like adding another qt |
On 30 Mar 2017 13:21, "Jonathan White" ***@***.***> wrote:
Websocket server requires boost libraries which are basically like adding
another qt
Well, it strongly depends on what you need. Most of the boost libraries are
#included as hpp files and compiled directly in the project so you really
pay for what you use.
|
@phoerious keefox will be re-written to cross-browser WebExtensions http://keefox.org/news/detail/2017/03/26/changes-to-keefox-in-2017 https://github.com/kee-org/browser-addon, so keepassrpc is a great choice, i think. |
passifox/keepasshttp don't seem to support deeper url syntax / matching, making it hard to support subdomains or subfolders / realms. Since keefox does support that I think moving in the rpc support direction would be better. |
I thought that WebSockets were native inside Qt5 for quite some time now which would simply add a dependency on another Qt module |
With the release of KeePassXC-Browser I believe this can be closed. |
Coming from here https://forum.kee.pm/t/use-with-keepassxc/311 what about Thunderbird? |
What about it? If that is something you want supported then create a new issue please. |
Implement a method to allow for browser integration.
As I understand it, both RPC and HTTP have security issues, that can't be fixed (yet?). I believe that work is being done on creating a substitute for them both, but I felt like this deserved it's own issue.
Or does the preference lie in fixing the security issue of RPC/HTTP?
The text was updated successfully, but these errors were encountered: