Allow expert mode to configure custom URL to KeePassHttp

[shaddybaddah]

First off, thank you for easing my worries at the loss of PassIFox. Of course there is a slight degradation in function at this early stage, but I accept that and appreciate the project and its contributors.

In the settings page, the configuration to target KeePassHttp is confined to a hostname and port. Of course a URL like the default http://localhost:19455 is generated, but that's the extent of it You can tweak the hostname and port. You cannot change to a HTTP over SSL uri scheme (https) or have a subpath.

Of course, 99%+ of users will stay within the confines of the simple configuration offered by both KeePassHttp and in lockstep this connector.

However, I have a bit of a funky config that requires a URL that includes https, an embedded username and password, and a subpath. There is a good intent behind that, and I have been running this for more than a year. It allows me to integrate a number of browsers with KeePassHttp at a home location, over the internet and on the go.

I have hacked this addon to customise the URL and run it using Firefox's addon debugging functions to determine if it would work. And it does.

That is of course, not the critical part. The critical part is how to alter the settings page so that it is balanced in a way that allows customisation without over complicating it for the regular user. I feel confident of achieving this myself and proposing it on here. But if the project maintainers have some suggestions on this, or even want to implement in their own style and fashion, these would be appreciated as well.

[smorks]

i am planning on changing how this extension works, to use Native Messaging to communicate with KeePass, rather than HTTP. it is supposed to be more secure than communicating over HTTP.

KeePassXC already has this in the works, and i've been working on the KeePassHttp plugin for KeePass to work the same way, and there already is another browser extension that is working in this fashion too, which also has some of the bugs in mine already fixed.

So unless there are other users out there that want to keep the HTTP communication to connect to something like you're doing, I don't see a point in maintaining this extension.

[shaddybaddah]

OK. I can see what is happening here... As you can tell from what I have written above, I was well aware of the potential danger of not encapsulating the KeePassHTTP traffic in SSL encryption, for my over the net solution. ie. the mention of the ability of a https scheme.

But because users could unwittingly do something as silly as send their traffic over unsecured networks without encryption, the solution being adopted is to de-feature the plugins. Native Messaging doesn't solve any immediate problem other than it means users are limited to "localhost only" traffic by design.

For sure, and I actually do like this about NM, it allows configuration to be cleaner, as a port will be a named port, and Native Messaging will handle the transport. But it seems a shame that everyone is running away from KeePassHTTP on a bit a false premise. If a user goes into advanced options, and change them in a way that exposes their passwords, that's on them. The documentation doesn't suggest anything like that. Because I knew well enough, I used SSL.

In any case, at this point I have to admit that this is the first time I've come to know of NM. So, I'll put pause on my disappointment and see if I can still achieve what I want by way of some proxy or something like that. On the face of it, it does look doable... however, I haven't yet looked deeper. If it is possible, that would be a cleaner solution all round.

[smorks]

with the way Native Messaging works, you could definitely use a proxy to pass the messages to a https endpoint. just for the majority of users, most of the traffic will be, like you said, on localhost, so we are trying to make that as secure as possible.