fix: set allowIframes=true in config + KDBX 4.1 corruption investigation

[th3nu11]

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:

Fork	My repo	PR to upstream
keeweb/kdbxweb	intresrl/keepass-kdbxweb	keeweb/kdbxweb#62 (open, likely unreviewed)
keeweb/keeweb	intresrl/keepass-keeweb	keeweb/keeweb#2277 (open, likely unreviewed)

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.

[arnowelzel]

Thanks for your support!

For the next couple of days I don't have time to prepare a new update, but I will get back to this next week.

[arnowelzel]

The PR itself only contains the change in the KeeWeb configuration. If I understand it correctly, the full fix would also require a change in the build to include intresrl/keepass-kdbxweb and intresrl/keepass-keeweb in the build pipeline.

I'm sorry, but I may not fully understand, what exactly would need to be changed here. The build pipeline checks out a specific version from https://github.com/keeweb. So what other repository should be used instead of this to test this fix?

[th3nu11]

You understood correctly. To incorporate the KDBX fix, your build pipeline would need to use intresrl/keepass-keeweb (branch intresrl) instead of keeweb/keeweb — that fork's package.json already points kdbxweb at intresrl/keepass-kdbxweb#intresrl, so everything pulls in transitively. Alternatively, the pre-built keeweb.php from my release branch can be used directly.

That said, I'm not sure the KDBX fix is worth the build dependency: as I mentioned in the PR description, I couldn't reproduce the original corruption with current KeePassXC. The intent here was mostly to document the investigation and get the allowIframes fix in. I'll leave the call to you.