Menu

#2798 Advanced I/O Connection Properties for Triggers

KeePass_2.x
open
nobody
None
5
2025-01-26
2023-02-16
Bartek
No

When creating trigger that synchronizes with a URL there is no possibility to set a 'pre-authenticate' option like when opening a URL. As a result KeePass will select a default option when performing sync via a trigger. This results in a 401 Unauthorized error when accessing some WebDAV providers e.g. CloudMe. This is because those providers force certain authentication scheme via HTTPS.

Please note this default means pre-authenticate=no on Windows and pre-authenticate=yes on Linux (may be mono-specific, didn't check). As a result the same trigger will authenticate correctly on Windows but not on Linux (again for some providers).

There is a pretty nasty workaround though. If you take the sync URL from the trigger, open it via Open URL option with the correctly set pre-authenticate option, the trigger will start working on the original (local) database also. That is KeePass's default changes meaning. This persists until the remote database is closed or until KeePass is closed, not sure.

To avoid this, there should be an option in the trigger parameters to set this explicitly. As a temporary workaround there could be a possibility to set this by hand in the trigger section of the XML configuration file.

I think this could be validated playing with request.PreAuthenticate in KeePassLib.Serialization::IOConnection::ConfigureWebRequest. I do not know the code too well to be sure though. However I can assist in whatever way I can, just let me know.

Discussion

  • Dominik Reichl

    Dominik Reichl - 2023-02-16

    The solution that you found is documented here:
    https://keepass.info/help/v2/triggers.html
    (section 'I/O Connection Properties').

    However, I agree that fields for advanced connection properties directly in trigger actions would be nice. Therefore, I'm moving this to the open feature requests.

    Thanks and best regards,
    Dominik

     
  • Dominik Reichl

    Dominik Reichl - 2023-02-16
    • summary: Triggers lack the pre-authenticate option --> Advanced I/O Connection Properties for Triggers
     
  • Dominik Reichl

    Dominik Reichl - 2023-02-16

    Ticket moved from /p/keepass/bugs/2223/

     
  • Igor

    Igor - 2025-01-26

    Few more closely related improvement suggestions:

    1. Although I previosly followed the https://keepass.info/help/v2/triggers.html workaround, at some point I've noticed that I got the same url twice in "File->Open Recent". Also I've got two <ConnectionInfo> items with equal <Path> (e.g. url) in my "KeePass.config.xml". One of them contains a lengthy <PropertiesEx> that contains, the HostKey (expected server host key fingerprint), and the other does not. It is misleading that they both managed to co-exist and there's no clear indication about which one is actually used for the Trigger. This feels like a potential pitfall. It is important to manually make sure you only have one correct version (because Host Key Fingerprint verification is important and I want to be sure it's enabled). Maybe there should be a clear indication about this relation (trigger Guid explicitly mentioned inside <ConnectionInfo>)?

    2. After a few experiments, I ended up manually editing the config file. Maybe it would make sense to improve this section of the config file a bit (make it more human-readable and human-writable), before/instead of creating a full-featured GUI dialog?

    3. If one leaves the password field in the "Action" form empty, a dialog (similar to "File->Synchronize->Synchronize with URL") pops up. On the one hand, this could be convenient, to actually set up the "Advanced properties". On the other hand, when using KeeAgent-based auth for the I/O Connection, I had to set a fake password to make this dialog not pop up. It would be probably more clean to have a separate explicit option to "ask for advanced connection properties on first/each connection" and also "no password/keyfile, rely on ssh key agent" (but still with host key fingerprint validation).

    4. It would be great if the "advanced connection properties directly in trigger actions" would support the "field references". Just like it is already suggested in "How to avoid storing credentials in triggers unencryptedly?".

    5. Just a similar feature request: #2634 (especially point 5).

     

Log in to post a comment.

MongoDB Logo MongoDB