SQLite database need to be installed in db folder

sites/default/db/main.db *would* be a great place to put the database file. The problem is not the sites/default folder, but is that you need to place the database file inside a writable folder.

Currently a sqlite database is installed in the drupal root folder alongside install.php and is accessible via http. This is no good.

The database needs to be installed in /sites/default/db/DBName or /sites/example.com/db/DBName. The db directory needs write permissions for the web user and it needs to be locked down so the database file is inaccessible.

The INSTALL.sqlite.txt says:

If you must place your database file in your webroot, you could try using the
following in your "Database name" field:

sites/default/files/.ht.sqlite

That's always worked for me.

I completely agree that the path should be outside the web root. That's the ideal location. But, most users are not going to know that. They will just choose a name and run with it. That is what I did. Nothing in the UI says where the file will be located or how this works. Instructions need to be on the form itself.

We cannot count on people reading all the different install instructions. Social engineering will leave a lot of insecure sites out there. We need to work around this in the same way we moved the PHP filter into its own module and disabled it by default.

Subscribing.

What about splitting up the database settings form during installation into two distinct steps:

1) Select your database driver
2) Configure the database driver

This would allow us to tailor the settings form based on the selected driver. For example, username, password and advanced options fields/fieldsets are not used for the SQLite driver and shouldn't be displayed. On the other hand, the SQLite form should come with big fat warnings like "Make sure the file is at all times writable", "Install the database outside of the web root" and "If you don't, for the love of all that is dear to you, make sure it's inaccessible to site visitors" since nobody bothers to read INSTALL.sqlite.txt anyway. A driver-specific validation step could be used to exclude certain paths as valid locations for the file, to prevent the issue reported in the OP.

Come to think of it: why should the installer decide what fields are required to configure a database connection? Seems to me that it makes more sense to have each database driver implementation tell the installer what information it needs to set up a connection.

It would also be nice to have a warning in hook_requirements that alerts the user when the sqlite database file is inside the webroot and accessible to site visitors, similar to the "your settings.php is not write-protected" warning already in there. However, I don't think it's possible to check whether or not a file can be accessed by site visitors in a cross-platform and reliable way so this probably won't fly.

No, we will not add another extra step in the installation process. It seems very easy, to just add another step - but it adds a huge load on the user to go trough a long process.

Bojhan, I'm not sure I agree. It also adds a UX WTF to have some fields that should be filled out only for some databases, but no indication of that i the install process itself. Even I get confused by what fields I should fill out for SQLite. :-)

I don't know if it's possible to have a fancier Ajax-fied form in the installer, but perhaps that's an option?

Well, then just hide some fields or add some in case of SQLite(AJAX) - but don't add another step. Really, we don't want to add another step, especially this late in the process - we already have too many UX WTF's.

Well, I'm not sure how much serious work we can do at this point. Ideally, we'd allow each database installer class to define its own form, then we build those all up together and use JS to display just the relevant one on the form, then save that information (give or take processing) to the settings.php file. I don't know if we can get away with that at this stage, though.

Presumably the way that would fix this issue is that we'd ask for a DB name only, and then put it in a dedicated directory of our choosing that would be htaccess protected. More advanced users can then move the file and edit settings.php themselves.

The idea of not placing it inside Drupal was that the SQLite database would reside outside the web root. This is a good idea. We can try to protect it via an .htaccess file. Even better is to have the database outside the web root. The install instructions for SQLite say to do that. But, whose going to read the install instructions?!?!

I agree with Crell that the ideal solution would be to choose a database and that database provide the appropriate form. This would change the API for D7 which is out at this point in the game.

For D7, I think we can provide a better description for the SQLite data name. One that is actually helpful.

What about #346494: DB drivers need to be able to change the configure database form during install allowing the dbengines to use hook_form_alter()?

I don't think changing the API for the installer if it applies to db engines only is out of the question by any means. There's only one contrib db driver I'm aware of, for oracle. hook_form_alter() wouldn't be an API change at all though.

Hello. Tagging.

The install screen for SQLite is now customized by the driver itself, and by default it suggests a location outside of the web root. I don't think any of the problems in this issue still stand; thus, closing.