Context

This PR follows up on the discussion in issue #282, specifically this comment warning about KeeWeb corrupting KDBX v4 databases on save.

I investigated the report, traced it to a bug in kdbxweb, built a fix, tested it end-to-end in a Nextcloud 33 Docker environment — and then discovered I could not reproduce the original crash with KeePassXC 2.7.12: the app opened the modified file without errors. It seems current KeePassXC releases accept both the correct Base64 format and the incorrect ISO-8601 string that the buggy version produces. If you know of another client or a specific scenario where the corruption is still observable, I'd appreciate a pointer.

⚠️ Dependency chain — read before merging

The full fix involves two forks of upstream projects that are effectively unmaintained. I am sharing this work in the spirit of open source, but I want to be transparent about what merging would imply:

jhass/nextcloud-keeweb  (this repo)
    └── bundles → keeweb/keeweb  ← unmaintained since 2021
                      └── depends on → keeweb/kdbxweb  ← unmaintained since 2023

My fix chain:

If you want to include the kdbxweb fix in this repo, the keeweb.php bundle would need to be rebuilt from intresrl/keepass-keeweb instead of the official keeweb/keeweb. Alternatively, you can grab the pre-built file directly from my fork's release branch:

Pre-built keeweb.php: intresrl/nextcloud-keeweb @ nc33-compat
(raw: https://raw.githubusercontent.com/intresrl/nextcloud-keeweb/nc33-compat/keeweb/templates/keeweb.php)

That is a significant commitment. I leave the decision entirely to you.

What's actually in this PR (the self-contained part)

Fix: allowIframes: true in the config response

- $config = ['settings' => (object) null];
+ $config = ['settings' => ['allowIframes' => true]];

This fix is independent of the kdbxweb issue and is useful on its own. KeeWeb 1.18.x introduced allowIframes: false as the default security setting. Since this plugin embeds KeeWeb in an iframe, the config endpoint must explicitly enable it — otherwise KeeWeb refuses to load with "Running in iframe is not allowed". This affects anyone who tries to update the bundled keeweb.php to a newer build.

The kdbxweb investigation (FYI, not in this PR's diff)

For reference, here is what I found and fixed in my forks:

Root cause (keeweb/kdbxweb, issue #49):
XmlUtils.setDate() was called without binary=true in two places when writing LastModificationTime for KDBX 4.1 databases:

• KdbxCustomData.write() — custom data items
• KdbxMeta.writeCustomIcons() — custom icon items

This wrote ISO-8601 strings instead of the 8-byte little-endian Base64 binary required by the KDBX 4+ spec. The fix is one line in each location (add , true).

See keeweb/kdbxweb#62 for the full diff.

Additional finding when generating keeweb.php: the newer KeeWeb bundle contains bare <? sequences in bundled JavaScript (XML processing instructions, startsWith("<?") checks, and Markdown link regex patterns). PHP interprets these as PHP opening tags. Every <? that is not <?php must be replaced with <?php echo "<?"; ?> when generating the PHP template.

Question for the maintainer

Is there a scenario — a specific KeePass/KeePassXC version, a particular database configuration — where the kdbxweb encoding bug is still observable today? If so, I would like to reproduce it to validate the fix more rigorously before recommending it further.