Use authorize.inc to securely copy settings.php during the installer

Created on 16 September 2010, almost 15 years ago

Updated 9 June 2025, 15 days ago

This is a D8-specific issue for implementing my proposal at #418302-90: Copy default.settings.php to settings.php during install IFF webserver owns files (FTP on shared hosting) → ... #418302 fixed the WTF for users where the webserver is running as the same user that owns all the Drupal files (i.e. many shared hosting configs). This is for the case where the webserver is running as a different user than the one that owns all the files. Re-pasting the relevant details of the proposal:

A) authorize.php itself isn't going to help us much, since it's depending on bootstrapping Drupal at least to the SESSION, which requires the DB, which requires DB credentials, which we don't have yet. However, all we really need is a FileTransfer object. Most of the form code to prompt the user for their credentials lives in includes/authorize.inc, so we can just re-use nearly all of that to instantiate a FileTransfer object, and then use that to do the file operations with the elevated privileges.

B) authorize.inc isn't quite cleanly separated from authorize.php enough to accomplish (A) yet, so we'll need a wee bit of refactoring to make authorize.inc not care about the SESSION in various places. Should be easy, and a good move. Any API (in this case, authorize.inc) needs at least two things trying to use it to be at all viable as an API. The current split was done very hastily, in the midst of a whirlwind of stress and lack of sleep. So, stepping back a little and seeing how it should really be organized to support being invoked from both authorize.php and install.php would be great.

C) Ideally, once install.php has this FileTransfer object for dealing with settings.php (and potentially db.php), it should pass it off to the install profile in case the install profile wants to use it for anything (e.g. fetching and installing 3rd party code during the install -- (see #594704: Allow packaged install profiles on d.o to pull in code from other sources + sites → for more). This is not a hard-requirement. An install profile could also solve this problem itself in contrib, but it'd involve prompting the user for all this information twice, which is clumsy for the UX, for no good technical reason.

✨ Feature request

Status

Postponed: needs info

Version

11.0 🔥

Component

install system

Created by

🇺🇸United States dww

Live updates comments and jobs are added and updated live.

Usability
Makes Drupal easier to use. Preferred over UX, D7UX, etc.

DrupalWTF
Worse Than Failure. Approximates the unpleasant remark made by Drupal developers when they first encounter a particular (mis)feature.

stale-issue-cleanup
To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Incomplete comments

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment 15 days ago →
🇺🇸United States smustgrave
Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!
Comment 15 days ago →
🇺🇸United States dww
authorize.php and the FileTranfser classes are now deprecated and slated for the dumpster.

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024