Updater UI for installation is broken

I've just encountered this error as well. No errors in apache logs, nothing in /admin/reports/dblog.

Summary updated and issue confirmed.

Confirmed - the page just refreshes with no error message. Raising to Critical.

This is being worked on at Amsterdam2014

Wat seems to be the issue is that the user gets redirected to https somewhere in the submit process. Steps to reproduce:

- Enable the Update Manager module
- Enter the URL of a tar file, eg http://ftp.drupal.org/files/projects/rules-8.x-3.0-unstable3.tar.gz
- Click Install

Possibly related: #842620: Update manager can't install modules using FTP due broken FileTransferAuthorizeForm

Confirming issue too. In my case I tried to add various different modules in the UI including Devel, Date and Admin Menu, using the various options available and it actually crashed my site, so I had to re install Drupal 8 from scratch. I would also like to add in a reference to another issue which is what caused us to discover this problem. https://www.drupal.org/node/2056089

There appears to be at least two issues.

Issue 1

For installation via a tar ball link, trying to install a module via the UI fails when the following two conditions are true:

1. The owner of the configuration directory is not the web server (e.g. apache is not the owner of the sites/default directory)
2. The site can only operating over insecure HTTP connection

We've stepped through the code to see what happens when you insert a project URL to install a new module.

In \Drupal\update\Form\UpdateManagerInstall::submitForm() the process is:

1. Check if the owner of the temporary directory is the same as the owner of the sites configuration directory
2. If it is not then the web server is not allowed to copy the module files, Drupal the decides it will use FTP/SFTP
3. system_authorized_init is then invoked to challenge the user for their FTP/SFTP details
4. This requires the user to be on a secure SSL connection and abruptly redirects users to HTTPS. If the website does not provide a HTTPS service or isn't configured to share

Possible resolution

There is a check that the site supports HTTPS before asking for FTP details.

Issue 2

For installation via a tar ball link, trying to install a module via the UI fails when the following condition is true:

1. The owner of the configuration directory is the web server (e.g. apache is the owner of the sites/default directory)

In \Drupal\update\Form\UpdateManagerInstall::submitForm() the process is:

1. Check if the owner of the temporary directory is the same as the owner of the sites configuration directory
2. If it is the owner then proceed with the installation process
3. Add an installation operation to a batch queue
4. Redirect the user back to /admin/modules/install

Step 4 is where the user started. There is no message to say the installation passed or failed. The module code has not been copied out of the temporary file store into the correct place. It looks like the final redirect in 4 is probably wrong and the user should be redirected to the page where the batch will be processed.

Testing required

Any solution(s) needs to test:

1. Installation of a module via URL on system where web server cannot write to module directory and site is HTTP only - there should be a graceful fail message as it is not possible to do this for security reasons.
2. Installation of a module via URL on system where web server cannot write to module directory and site is HTTPS only - this should prompt for FTP details and then install over FTP.
3. Installation of a module via URL on system where web server cannot write to module directory and site is mixed mode HTTP and HTTPS - this should redirect to HTTPS if not already, prompt for FTP details and then install over FTP.
4. Installation of module via URL on system where web server can write to module directory - This should install correctly

@ceng

Just some observations about shared hosting companies here in Brazil.
Apache owner is only used by the company, never by its customers. Because of security reasons.

Each costumer has a different user with read/write access for his/her own sand box (www and ftp).
Via PHP normal routines, each customer can read/write to files and directories, including download, upload, extract, change permissions on files/directories for his/her own sand box (www and ftp).

Many small shared hosting companies do not have or do not use HTTPS.
Sometimes the customer have to pay extra money for using HTTPS. Not every customer pays this extra tax.
So, if possible, Drupal 8 should install using only HTTP/FTP simple account.
If this would be a security risk, Drupal should have a setting allowing or not this kind of operation leaving this decision to the administrator of the site.

Via ssh or putty, the Drupal developer using this simple user provided by the shared hosted company can download, extract and install modules as much as uninstall and delete directories/files.

The problem is that the final customer want this kind of operation to be made by him/herself without needing the Drupal developer interference.
The final customer neither know how to use Linux, nor ssh, nor putty.
Thats why we need so much to install new modules via UI.

Thanks.

I'm having the same issue running 8.0 beta locally using Acquia Dev Desktop. It's a serious usability issue. As for the UX, there is no indication what is amiss--only screen refresh happens when I do it, which gives the user absolutely no indication of what is amiss...

Having the same problem running 8.0.0-beta1 . I cannot enable any modules, neither contrib nor core. The screen refreshes without any message being displayed, and the selected modules are not enabled. There is the same problem with uninstalling modules.

@NagareHoshi that sounds like a different issue that in the summary, can you look for or open a new issue for that one?

This issue is about installing modules through the install form in the admin. Which downloads and unzips into the module directory automatically.

I opened #2352637: Remove the UI for installing/updating modules from update module if it is not fixed in time for release as an option to get this 'fixed' if it's one of the final release blockers for an 8.0.0 release candidate. That shouldn't stop people working on a fix here and trying to get it in, still time for that to happen.

I did some debugging on this, and it looks like the problem is that the batch is being created and saved properly in update_authorize_run_install(), but the batch isn't being run. If you watch on the network log, the POST happens, and it gets back a HTTP 303 back to the admin/modules/install page.

Everything looks OK in system_authorized_batch_process(), and the RedirectResponse that gets created looks OK, too. I am definitely not seeing the initial redirect to core/authorize.php that kicks off the process.

Not sure where to look after this. Guidance appreciated, and I will work on a patch.

I tested the issue too and I'm getting two different cases:

First case

- Give the module tarball or direct url in the admin page (under http site)
- Redirect to /core/authorize.php (under https) and I'm having an access denied error.
UPDATE: If I'm going on the page under HTTPS then back on HTTP it's working, seems like the error is on the authorization check

second case

- Give the module tarball or direct url in the admin page (under https site)
- Redirect to /core/authorize.php with authorization this time
- Get the FTP configuration interface

Once I have filled the FTP information, I cannot save them. (will open an new issue for this).

Testing env

8.0.x branch out of the box
Zend Server enterprise (Apache/MySQL/PHP 5.4.29)

Proposed Work

We should decide if we allow the upload and transfer under HTTP (we can imagine a checkbox like "use at your own risk").
If this is a security issue under authorize.php process, we have to find another way to install by the UI for non HTTPS protocol (it's not a good idea to block this functionality, lot of small website won't have an SSL certificate).

I don't have SSL on any servers to see if this will authorize properly, but this at least initiates the redirect from the second scenario mentioned in #8.

Setting Needs Review so I can see what Mt TestBot says.

@mpdonadio thanks for the patch a quick run shows it is redirecting... but it goes to an incorrect URL it seems:

The requested page "/core/authorize.php%3Fbatch%3D1" could not be found.

I think /batch is where it's supposed to go and /core/authorize.php is supposed to be where it ends up after. IIRC.

This issue may also be a dupe but look here for inspiration if it helps #2042447: Install a module user interface does not install modules (or themes) close this if it is a dupe.

Hmmm. That was the URL in the redirect object I got back, but you are right. I guess I was chasing the wrong thing.

I have read through both issues a few times, and I think this is a dup of #2042447: Install a module user interface does not install modules (or themes)