fix: improve SQLite support, fixes #46

[codebymikey]

The Issue

• Fixes can't install when no db installed (I'm using SQLite) #46

SQLite database are hard to open at the moment, because the default adminer user runs with a uid 100 which typically differs from the uid used by the user.

How This PR Solves The Issue

• Ensures that the host user's uid is used to run adminer.
• Add a passwordless plugin to the template - done this way rather than always enabled so users who do not need the passwordless functionality may easily disable it.

Manual Testing Instructions

ddev add-on get https://github.com/ddev/ddev-adminer/tarball/refs/pull/51/head
ddev dotenv set .ddev/.env.adminer \
    --adminer-default-driver=sqlite \
    --adminer-default-username="" \
    --adminer-default-password="" \
    --adminer-default-server="" \
    --adminer-default-db=/mnt/ddev_app/demo.db
ddev restart

# Create the sqlite database
ddev exec --raw -- sqlite3 demo.db "CREATE TABLE items(id INTEGER PRIMARY KEY, name TEXT); INSERT INTO items(name) VALUES ('alpha'), ('beta');"

# Open adminer
ddev adminer

# Then load up the SQLite database using `/mnt/ddev_app/demo.db`.

Connect to the SQLite database:

SQLite database content should now be visible:

Automated Testing Overview

Release/Deployment Notes

[stasadev]

Thank you @codebymikey !

Does this new ddev-passwordless-login plugin can work with other database types as well? I wonder if we can remove ADMINER_DEFAULT_PASSWORD completely.

We also need to have some test coverage for SQLite (similar to what we have in other tests, check for redirect to the correct page).

BTW, I refactored ddev exec logic several releases ago, and it should work:

-ddev exec --raw -- sqlite3 ...
+ddev exec sqlite3 ...

[codebymikey]

Add the bats test case for sqlite, as well as checking if the site was able to successfully authenticate.

The redirect check by itself did not suffice for that.

Does this new ddev-passwordless-login plugin can work with other database types as well?

Yes, it should, however, I updated the plugin logic so that the passwordless behaviour is only for SQLite (for now), mainly for backwards-compatibility/security purposes (and those needing it for other databases, can override or add their own plugins).

However, if you want to provide it for every driver, then feel free to update the PR, or introduce a new variable to make the passwordless global.

I wonder if we can remove ADMINER_DEFAULT_PASSWORD completely.

I thought the default mysql or pgsql users did require setting the db passwords - if so, then I think the password must still be specified in adminer (but I haven't tested).

[stasadev]

Thank you! Looks good to me.

Yes, it should, however, I updated the plugin logic so that the passwordless behaviour is only for SQLite (for now), mainly for backwards-compatibility/security purposes (and those needing it for other databases, can override or add their own plugins).

I thought the default mysql or pgsql users did require setting the db passwords - if so, then I think the password must still be specified in adminer (but I haven't tested).

I think you're right. We have autologin for ADMINER_DEFAULT_PASSWORD in all databases, but if people don't want that, they can simply remove the ddev-adminer.php config, and it's going to work as the expect.