Problem/Motivation
Install new module give AJAX error: 404 on /core/authorize.php/core/authorize.php
Problem exists on Nginx and PHP built-in webserver, but not with Apache.
Steps to reproduce:
0. Install Drupal somehow, if its installed change to its directly goto step 3
1. drush qd --profile=standard --core=drupal-8 -y d8rc1test
2. cd d8rc1test/drupal-8
3. drush rs /
4. Log in
5. click on "Extend"
6. click on "+ Install new module"
7. Paste in any module link, e.g. http://ftp.drupal.org/files/projects/devel-8.x-1.x-dev.tar.gz
Result:
Note that if you follow the same steps above in a browser with JavaScript disabled, you receive a similar "Page not found" error for core/authorize.php/core/authorize.php.
The reason that this error works on the Apache webserver is that, when Apache is processing "core/authorize.php/core/authorize.php", it evaluates each part of the path in sequence. When it notices that there is an executable file "authorize.php" at the relative location core/authorize.php, it executes that script, passing it the entire request URI, "core/authorize.php/core/authorize.php". Apache is therefore resilient to this error. Other web servers that treat the entire request as a distinct path, on the other hand, fail to find the authorize.php script and return a 404 instead.
Proposed resolution
The target URL is being correctly generated via `Url::fromUri('base:core/authorize.php');`, which behaves correctly; however, UnroutedUrlAssembler.buildLocalUrl() does not assemble the correct target URL in all cases.
Therefore it does
global $base_path
is exposed on the request context:$erequestContext->indexPhpBasePath()
- This method name was chosen to make it as explicit as possible and reduce a potential misunderstanding with the existing base path (which is the base path of the current front controller, which is identical in case of index.php, but not fore update.php/authorize.php
- The URL asseembler then uses the global $base_path to generate the resulting URL
- There used to be magic to add the front controller to the generated URL. This was removed as we now use ALWAYS the
$base_path
, and this is it. - Note: This lets
base:
behave in a consistent way aka. be relative to index.php instead of another front controller
Remaining tasks
Needs RTBC
Why this should be an RC target
.
This issue is not critical, and does not qualify for rc eligible. However, this fixes a serious problem in a core API that is widely used. The risk of changing the implementation of a widely-used core API needs to be balanced against the risk that this bug could easily manifest in other situations. Tracking down this problem is difficult. Also, if not fixed, some web servers, such as Nginx, will not work correctly with all Drupal 8 features.
User interface changes
None.
API changes
None. Fixes a flaw in an existing API which was not correctly fulfilling its contracts.
Data model changes
None.
Comment | File | Size | Author |
---|---|---|---|
#94 | interdiff.txt | 13.7 KB | dawehner |
#94 | 2583799-94.patch | 1.69 KB | dawehner |
#91 | 2583799-91.patch | 19.28 KB | dawehner |
#91 | interdiff.txt | 4.13 KB | dawehner |
#89 | 2583799-89.patch | 10.83 KB | greg.1.anderson |
Comments
Comment #2
cilefen CreditAttribution: cilefen commentedI could not reproduce this my local Apache server, but I could on the built-in PHP server running
drush rs
as described in the summary.On the console for the built-in server there are lots of these:
Comment #3
greg.1.anderson CreditAttribution: greg.1.anderson commentedThe commonality here might be non-Apache webservers.
Comment #4
dawehnerThe problem is somehow that the URL generated for the batch request itself, not the initial request to /core/authorize.php looks like
/core/authorize.php
Adapted the issue summary to make it even easier to reproduce.
Comment #5
cilefen CreditAttribution: cilefen commentedSlightly, possibly, maybe related: #2353907: update.php requires trailing slash or returns 404 with nginx
Comment #7
RandomSeb CreditAttribution: RandomSeb commentedI have this issue installing or updating modules through the UI, running nginx and drupal8-rc1 (redownloaded today).
I have found that the ajax call is wrong.. it is trying to call:
http://my.domain.com/core/authorize.php/core/authorize.php?batch=1&id=22...
/core/authorize.php/core/authorize.php
For whatever reason /core/authorize.php is being added to the ajax call twice.
I manually loaded:
http://my.domain.com/core/authorize.php/?batch=1&id=22&op=do_nojs&op=do&...
And it completed the operation successfully:
{"status":true,"percentage":"100","message":"Completed 2 of 2.","label":""}
I will now dig through the relevant code to try to find why it would be adding an extra /core/authorize.php (or perhaps it is just doing that and apache ignores the path error for whatever reason?)
Comment #8
RandomSeb CreditAttribution: RandomSeb commentedI solved this with a bandaid on nginx, in my web server config:
(that domain is fake of course)
Comment #9
greg.1.anderson CreditAttribution: greg.1.anderson commentedIt does appear that Drupal Core is requesting core/authorize.php/core/authorize.php, even when running under Apache. I guess Apache matches the first core/authorize.php against the file that exists at that location, and does not care that the extra core/authorize.php is there. nginx and the Apache built-in web server are not as accommodating, though.
Comment #10
greg.1.anderson CreditAttribution: greg.1.anderson commented`system_authorized_batch_process()` generates the correct URL, and the first redirect to core/authorize.php is correct, but by the time we have reached core/authorize.php itself, the Batch URL contains `/core/authorize.php/core/authorize.php?batch=1&id=12&op=do_nojs`. Still not sure where this comes from.
Comment #11
cilefen CreditAttribution: cilefen commentedComment #12
greg.1.anderson CreditAttribution: greg.1.anderson commentedThis problem actually does not have anything to do with Ajax or Javascript. The same error occurs if you turn off JavaScript; the only difference is that you get a "page not found" for core/authorize.php/core/authorize.php instead of an Ajax error. This problem is therefore generally easier to trace with Javascript turned off.
The bad URL is returned from system_authorized_get_url():
_batch_progress_page() attempts to generate the redirect url from $batch['url'], which was provided by the above function.
\Drupal\Core\Utility\UnroutedUrlAssembler.buildLocalUrl() does the actual assembly. The problem is that $request->getBasePath() is "/core/" , and $options['script'] is "authorize.php/"; since our current page request is core/authrorize.php, this is correct. The current uri at this point is "core/authorize.php", as provided. These things are all concatenated together, so it behaves as implemented, and core/authrorize.php/core/authrorize.php is generated.
Changing system_authorized_get_url() to Url::fromUri('base:/core/authorize.php'); (note additional leading "/") is ineffective, because buildLocalUrl() explicitly removes leading slashes. This is necessary for other use-cases for this code.
Ideally, we would like to see our URI in buildLocalUrl() be "base:" instead of "base:/core/authorize.php", but we cannot simply change system_authorized_get_url() to return this value, as system_authorized_get_url() is also used at the beginning of the request to redirect to core/authorize.php at the beginning of the batch process.
So, in short, I have found the problem, but do not yet have a simple solution that works without breaking other things.
Comment #13
greg.1.anderson CreditAttribution: greg.1.anderson commentedIn #12, I started with the assumption that buildLocalUrl() behaved correctly, and that the solution would be to get the correct data to this function such that it produced the correct result. With further investigation of the data sent to this routine in different situations, it became clear that the target values were correct -- the callers know what URL they want to go to, this is easy -- the problem was that buildLocalUrl() was not correctly handling URL generation when (a) the target was a php script (e.g. authorize.php), and/or (b) the target was not at the Drupal root (e.g. /core/authorize.php).
The attached patch checks for both of these conditions, and compensates appropriately, so that the correct target URL is always generated. With this patch applied, both the Javascript and the no-Javascript cases work correctly, and it is possible to install modules through the update module on Nginx.
It seems that when this routine is functioning correctly, the $base_url is "/" and the script is empty. In other instances (e.g. core/authorize.php), the resulting URL doubles up the path in a way that happens to work on Apache, limiting the exposure of this bug. I have not found any instances where this bug manifest other than as reported here.
Comment #14
greg.1.anderson CreditAttribution: greg.1.anderson commentedComment #15
almaudoh CreditAttribution: almaudoh commentedGood work to find the problem. I've not really looked in-depth but I think this is where the problem lies:
Url::fromUri('base:....')
should return a url based off the Drupal install path, irrespective of the location of the running script (whetherindex.php
orcore/authorize.php
). It's behavior should be predictable.Comment #16
greg.1.anderson CreditAttribution: greg.1.anderson commentedPerhaps #15 was written prior to #13. Url::fromUri() is returning a data structure that is correct; it is UnroutedUrlAssembler.buildLocalUrl() that mis-renders it in certain situations. In any event, I appreciate the feedback.
The submitted patch still needs testing (and tests) covering other situations, including:
1) Installing Drupal in a subdirectory.
This probably works with the submitted patch unless the subdirectory is named "core". I need to confirm this, and possibly adjust the patch.
2) Using Drupal without clean URLs.
I have not tried this, but I suspect that installing modules through the update module's admin UI might fail without this patch. Adjustments to the fix here might also be necessary for this use case.
I hope to be able to spend more time on this later today or tomorrow, but collaboration appreciated.
I am upgrading the severity of this issue to "major", because buildLocalUrl() is an important core API, and it is currently not fulfilling its contracts correctly, to the detriments of platforms that should be supported by Drupal (Nginx, et. a.). This bug might impact other present behaviors not yet discovered, or cause problems with future code. I do not believe that it meets the criteria of a critical, though.
Comment #17
greg.1.anderson CreditAttribution: greg.1.anderson commentedConfirmed #13 also works on the php built-in web server.
Comment #18
greg.1.anderson CreditAttribution: greg.1.anderson commentedConfirmed #13 also works with non-clean URLs in a subdirectory, *except* that at the very last page, the links are not correct.
Starting URL:
http://test8.dev:7777/subsite/index.php/admin/modules/install
Links on confirmation page:
"Install another module" -> http://test8.dev:7777/subsite/admin/modules/install
This is probably because, in my patch, I necessarily need to redirect from '/subsite/index.php' to '/subsite/core/authorize.php', not '/subsite/index.php/core/authorize.php'. Once we are at '/subsite/core/authorize.php', buildLocalUrl() has no good way to know that it should go back to '/subsite/index.php/'. Not sure how the existing code was expected to work in this instance; it could be that I do not have my site configured correctly. i.e., I do not have $base_url set, as it appears this variable is set up automatically in Drupal 8.
Comment #19
greg.1.anderson CreditAttribution: greg.1.anderson commentedAh, regarding #18, I see that clean URLs are required in Drupal 8, so the non-clean URL case does not need to be considered.
Comment #20
greg.1.anderson CreditAttribution: greg.1.anderson commentedConfirmed #13 works with clean URLs in a subdirectory, e.g. http://test8.dev:7777/subsite/admin/modules/install
Comment #21
cilefen CreditAttribution: cilefen commentedSince the cause was found to be outside of the extension system, should we change the component field on this issue to "base system" or maybe the "routing system"?
Comment #22
greg.1.anderson CreditAttribution: greg.1.anderson commentedTried to install Drupal 8 into a subdirectory named "/core" (i.e. /path/to/drupal/core/core/authorize.php), and found that breaks everything including rendering of the home page, even without this patch installed. I did not investigate the cause or causes for this, but I do remember seeing at least one place where the string "core" is removed if it exists at the beginning of a URL.
Perhaps this is acceptable behavior (don't install Drupal 8 in a subdirectory named "core")?
Comment #23
greg.1.anderson CreditAttribution: greg.1.anderson commented@cilefen: Yes, I also thought that changing the component to something else would be appropriate, but I did not see a component specifically for the URL component, which is in Drupal/Core/Utility. Although the symptoms of this bug have to do with routing, the bug only manifests for non-routed URLs, so I think that "routing system" is perhaps not the best choice, unless Drupal/Core/Utility is considered to be de-facto part of the routing system. Perhaps "base system" is most appropriate?
Comment #24
cilefen CreditAttribution: cilefen commentedLet's go with "base" then.
Comment #25
cilefen CreditAttribution: cilefen commentedComment #26
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedThanks for writing some tests. I added another one that more closely mimics the calling environment of the original use-case where the failure was discovered.
Comment #27
cilefen CreditAttribution: cilefen commentedMy options array with the script setting could be off the mark.
Comment #28
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedOh, didn't notice what you had done in $options there; just copied it over. That might indeed fail; I guess for now we'll just let the tests finish running and see how they come out.
Comment #31
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commented@clifen: Okay, your test got a fail and a pass, which is good. I think that the 'script' option is irrelevant here, but your test still covered about 50% of the change introduced in the patch, so it is a good test. I was going to change it to 'base:bar/foo.php', though (removing leading slash); the existing test for /drupal.org is testing to ensure that there is no doubled-up slash at the beginning of the generated URL if a leading slash appears on the input URL, but the recommended / expected / usual case here is no leading slash on "base:" URLs. I don't know if it's worth the time to take out the 'script' option and leading slash; might be slightly more correct to do that, but doesn't hurt anything as it is.
I didn't run my tests locally yet; we'll see if they come out with a fail & a pass as well.
Comment #32
cilefen CreditAttribution: cilefen commentedThe quickest way to run it:
phpunit -c core --filter UnroutedUrlAssemblerTest
Comment #33
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedThanks for the phunit commandline -- helpful!
Looks like all of the tests are coming out as expected, and we have all of the necessary use cases covered. I'll rewrite the summery per https://www.drupal.org/issue-summaries and https://www.drupal.org/core/d8-allowed-changes to see if we can get an RTBC and 'rc target' tag on this.
Comment #34
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedComment #35
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedSimplified a couple of the tests slightly.
Comment #36
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedI don't think the tests are testing what they are supposed to be testing. I will look at this a bit more tomorrow, and then update the status again.
Comment #37
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedNeither my tests nor @cilefen's tests were duplicating the web server environment quite correctly. These new patches include improved tests with correct mocks, so the failing tests now look the same as what is observed in a web server.
I also reworked the fix in this patch for both of the behavior changes introduced.
1. The '/core/' directory is now explicitly removed. This mimics what is done in DrupalKernel.initializeRequestGlobals() when it sets up $base_path. There is some question about how this code should be factored; since DrupalKernel.initializeRequestGlobals() is deprecated, I decided to duplicate the functionality rather than introduce a dependency that will need to be cleaned up. Note that the construction of $base_secure_url and $base_insecure_url is also duplicated in UnroutedUrlAssembler.buildLocalUrl(). I also left this code unchanged, for the same reason previously stated, and also to minimize changes to the function being fixed.
2. I attempted a simpler fix for handling the $script component, but it did not correctly handle scripts such as update.php, so I went back to my original fix.
Tested successfully under the PHP built-in webserver, and using Nginx on the Pantheon platform.
Comment #38
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedUpdated summary. Described why this is not a problem under Apache, and updated the "Remaining tasks" section.
Comment #41
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedTrying to re-upload my patches, as the TestBot was not picking them up before.
Comment #42
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commented#37 did not correctly account for scripts such as update.php, so I went back to my original solution in #41.
Comment #43
tim.plunkettIssue must be marked NR for the bot to care
Comment #44
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedThank you @tim.plunkett! Didn't notice that I forgot to do that.
Comment #51
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedThe testbot decided to queue and re-run all of the tests after I deleted #41, and re-uploaded a new copy of the issues. Note that #41-test.patch failed as expected, and the #41.patch passed.
Comment #52
alexpottDiscussed with @catch and we agree that this is nasty and therefore should be committed during RC.
Comment #53
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedDamien Tournoud provided some helpful advice on an alternate workaround:
He suggested replacing the default with the following expression:
fastcgi_split_path_info ^(.+?\.php)(|/.*)$;
I was not able to get that to work myself. In any event, it would be helpful to get the RTBC'ed and committed, as this bug could potentially manifest in other scenarios as well.
Comment #54
populist CreditAttribution: populist commentedI think it is important that Drupal 8 works without requiring the kind of custom NGINX configuration as mentioned in #53. This is especially true for operations like adding modules through the GUI which are typically undertaken by users less inclined/able to do custom NGINX rules.
I went ahead and tested the patch in #41 using an NGINX web server. Without the patch, the user gets an error when trying to install a new module using the GUI. With the patch, the user gets the module installed (assuming the web server is writable).
Comment #61
tim.plunkettComment #62
dawehnerHere is a question, why can't we use
global $base_path
or rather move that kind of base path onto the request context and use it via there?Comment #63
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commented@dawehner: I did not want to use the existing `global $base_path` because that code is marked as deprecated, and I did not want to add a new reference to it. There is already duplicated logic in this part of the code vis-a-vis the $base_path calculation, so it seemed better to do it the way that I did. Using `$base_path` would also be a perfectly valid solution, in my mind no better or worse.
The correct solution, of course, is the second solution you hint at: the request context should be correctly calculated, so that all code that relies on it can count on its validity. However, I was concerned about the potentially large impact such a change would have. I felt it was better to put off this change until 8.1, and make a lower-impact change that, while not pretty, at least makes the function calculate the correct result instead of an incorrect result.
It's down to the wire; I'm hoping that 8.0.0-stable will have a working UnroutedUrlAssembler rather than a broken one. I'm happy to switch to any technique that will get the job done, but at this point I don't think every option is feasible, given the limited time available.
Comment #64
dawehnerLet's see whether this is it.
Comment #65
heykarthikwithuspelling mistake "Sets".
Comment #67
dawehnerBreaking fundamentals is problematic, always
Comment #69
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedMake the parameter order in core.services.yml match the parameter order in UnroutedUrlAssembler constructor.
Comment #70
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedNice bot tests patch.
Comment #73
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedI did some ad-hoc testing with #69. It does correctly allow the module installation feature to work; however, if you visit http://example.com/update.php, then the link on the "Continue" button is http://example.com/selection instead of http://example.com/update.php/selection.
Comment #75
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedThe good news is that the number of failing tests is greatly reduced in #69, and those that are failing appear to be directly related to #73. e.g.:
The test is failing because it ends up at http://localhost/checkout/selection instead of http://localhost/checkout/update.php/selection.
Investigating.
Comment #76
dawehnerThis could solve like most of the issues
Comment #77
dawehnerFixed the unit test for real.
Comment #78
dawehnerWorked on the issue summary ...
Comment #81
dawehnerThis is a late in the night but total different approach patch.
Comment #82
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedYou've got a couple of var_dump's in your patch, but other than that, I am very hopeful about the outlook for this approach.
Comment #83
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedI've only had a couple of minutes to do ad-hoc testing, but #81 is redirecting to core/core/authorized.php (got rid of an extra authorized.php, but an extra 'core' remains).
Maybe
Url::fromUri('base:authorize.php', ['base_path' => trim($GLOBALS['base_path'], '/'), 'script' => '']);
would do the trick; will try that next.Comment #84
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commented#83 brings us to authorize.php (core/core removed), so that won't do either.
Comment #85
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedOn the subject of whether or not Drupal 8 requires clean URLs or not the page https://www.drupal.org/requirements/webserver says:
There is a similar disclaimer for Nginx. However, in the Requirements section if core/INSTALL.txt, it says:
So, it would seem that the web page is probably wrong, and INSTALL.txt is probably right. Alex Pott said in IRC that clean URLs is not required.
Comment #86
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedI changed my mind about #81. I do not think that I like it after all, because it relies on changing the way that the caller uses
Url::fromUri()
. While this has initial appeal in terms of minimizing impact, the larger problem is that the longer this problem goes unaddressed, the more places in the code we will need to fiddle with the parameters toUrl::fromUri()
to get the right result. #2548095: Add option to Url() to force the site base_url to be used also attempts to take this route, adding flags to the options; I think it is a mistake. Far better to ensure that all of the callers of this function are correct and consistent, and encapsulate the workarounds, as needed, inside the implementation.#77 was the right idea. It corrected the inconsistency between how update.php and authorize.php expected
Url::fromUri()
to work. It also removedindex.php
from the resulting URL, a simplification it seems we are not ready to make (c.f. #85). I think that continuing with #77 will get us to the right solution, but it will need some work.Now, the advantage to #41 is that all its tests pass, and it maintains the ability to run without clean URLs. Here is a new patch that combines the update.php consistency from #77 with the other parts of #41. Let's see if all of the tests pass with this patch, and then figure out where to go from here.
Comment #87
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedOne step at a time. There's no point in getting rid of the "/core/" hack in my patch until we get rid of it in the $base_url calculation. This patch enhances #86 to do just that. If these tests all pass, then I will go on to the next step.
Comment #89
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedFix typo in #87.
Comment #91
dawehnerI'm wondering whether we should explore more the old route ... to be honest, so what about doing something like this?
Comment #93
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedI can agree to adding options to FromUri as long as:
1. $base_url or other globals do not need to be referenced when creating a URI
2. There can be a function such as
system_authorized_get_url()
that is called both from the standard front controller and a custom front controller (e.g. core/authorize.php), and the result is usable in either context without system_authorized_get_url() needing to know the context it was called from.Looks like #91 satisfied both of those criteria.
The request context already has a reference to $base_url, so adding $base_path here does not make things any worse. This can be cleaned up at a later time.
I presume that 'urlj' should just be removed. I haven't had a chance to look at the failures yet, but if these can be fixed easily, then this is a good route to take.
Comment #94
dawehnerOh yeah, this was just a temporary idea.
Yeah exactly that was the idea, even I still think, that adding the front controller by default is wrong, but this can be discussed in a follow up.
So I'm wondering whether the following patch is actually all we need?
Comment #96
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commented#94 is still redirecting to core/core/authorize.php.
Comment #97
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commented#91 works perfectly in ad-hoc testing. I did not confirm why the tests are failing in #91 and #94, or why #94 is not generating the correct result.
Comment #98
bskydive CreditAttribution: bskydive commentedbug are still present in drupal 8.0.5 + php7.0.5(zend 3.0.0)+ CentOS7+ nginx1.8.1 + php-fpm + postgreSQL9.5 with workaround in nginx.conf:
https://www.nginx.com/resources/wiki/start/topics/recipes/drupal/
Can't install via web-admin:
https://ftp.drupal.org/files/projects/drupal8_zymphonies_theme-8.x-1.0.t...
Error: 403 Forbidden nginx
after applying patch #91 drupal became broken:
*7 FastCGI sent in stderr: "PHP message: TypeError: Argument 2 passed to Drupal\Core\Utility\UnroutedUrlAssembler::__construct() must be an instance of Drupal\Core\Routing\RequestContext, instance of Drupal\Core\PathProcessor\PathProcessorManager given, called in /home/MhPtaxBy7/drupal/core/lib/Drupal/Component/DependencyInjection/Container.php on line 273 in /home/drupal/core/lib/Drupal/Core/Utility/UnroutedUrlAssembler.php on line 56" while reading response header from upstream, client: 192.168.1.111, server: vm.drupal, request: "GET /admin/theme/install HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host: "vm.drupal", referrer: "http://vm.drupal/admin/appearance"
Comment #99
xjmThis was previously marked as an RC target for 8.0.0; however, the current proposed approach looks patch-safe. So removing the tag. We might consider a more complete fix in 8.2.x if needed.
Comment #101
borepstein CreditAttribution: borepstein as a volunteer commentedI have experienced the same thing, only I got HTTP code 403:
https://www.drupal.org/node/2780307
Not that that is necessarily significant but I thought I'd mention that.
I got exactly the configuration mentioned above: Nignx, PHP, PHP-FPM, Drupal 8, etc.
Boris.
Comment #102
rpmskret CreditAttribution: rpmskret as a volunteer commentedI installed a new drupal 8 site yesterday (drupal 8.1.8). Today I cannot install a theme via the web interface. This appears to be caused by the same issues as the drupal core issue posted here. Here is some information courtesy of my website:
This seems to be a pretty major issue and I hope this helps.
Comment #104
cilefen CreditAttribution: cilefen commented@catch, @effulgentsia, @xjm and I discussed this issue and we agree that it is properly prioritized at major, considering its impact and scope. @Cottser and @alexpott supported the decision in separate communications. It would be interesting to see if this is reproducible on IIS, although that would not on its own change the priority.
Comment #105
boozemun CreditAttribution: boozemun commentedI get the same error with Drupal 8.2.5 using Mac OS Server 10.12 and MySQL:
Update manager
Notice: Undefined index: log in update_authorize_install_batch_finished() (line 293 of core/modules/update/update.authorize.inc).
Warning: Invalid argument supplied for foreach() in update_authorize_install_batch_finished() (line 293 of core/modules/update/update.authorize.inc).
Notice: Undefined index: log in update_authorize_install_batch_finished() (line 334 of core/modules/update/update.authorize.inc).
Notice: Undefined index: tasks in update_authorize_install_batch_finished() (line 335 of core/modules/update/update.authorize.inc).
Installation failed! See the log below for more information.
I've given up on Drupal 8 problem after problem forget it
Comment #107
paluna CreditAttribution: paluna commentedI am getting the same error consistently.
Software stack:
- Drupal drupal-8.2.6
- Ubuntu 14.04.2 LTS
- Apache/2.4.23
- PHP 7.0.6-1+donate.sury.org~trusty+1
- php7.0-fpm:amd64/trusty 7.0.6-1+donate.sury.org~trusty+1
Notes:
- mod_security2 is enabled but it does not block Drupal in any way.
- I tried to de-duplicate the URL but that results in the same error. ProxyPassMatch ^/(core/authorize\.php/core/authorize\.php(.*)?)$ fcgi://127.0.0.1:9001/var/apache-www-80/core/authorize.php disablereuse=On retry=10
Error when installing a theme: Error page#1:
An AJAX HTTP error occurred.
HTTP Result Code: 403
Debugging information follows.
Path: /core/authorize.php/core/authorize.php?batch=1&id=38&op=finished&op=do
StatusText: Forbidden
Error page #2:
Notice: Undefined index: log in update_authorize_install_batch_finished() (line 293 of core/modules/update/update.authorize.inc).
Warning: Invalid argument supplied for foreach() in update_authorize_install_batch_finished() (line 293 of core/modules/update/update.authorize.inc).
Notice: Undefined index: log in update_authorize_install_batch_finished() (line 334 of core/modules/update/update.authorize.inc).
Notice: Undefined index: tasks in update_authorize_install_batch_finished() (line 335 of core/modules/update/update.authorize.inc).
Installation failed! See the log below for more information.
=> What I am doing right now is upload the theme or module manually and then activacte it using the Admin UI when needed. It is not the optimal procedure but it works. A fix would make configuration and deployment much easier, especially for new Drupal developers like me.
Comment #110
mdesimone CreditAttribution: mdesimone as a volunteer commentedI have this exact same error.
Drupal 8.5.0
PHP 7.1.15
nginx 1.13.9
Using a fork off the git repo. My master branch started from tag 8.5.0-rc1 and merged in tag 8.5.0. So I'm in a pretty good position to test stuff; there's effectively no code of mine in there.
Basically, I'm starting from a fresh 8.5.0 install and trying to install @font-your-face 8.x-3.2.
Nginx config block passing control to PHP-FPM:
I have no idea what patch above to apply. For now I'll apply the Nginx workaround found here:
rewrite ^/core/authorize.php/core/authorize.php(.)$ /core/authorize.php$1;
Comment #111
lightweight CreditAttribution: lightweight commentedI'm getting the same error as @paluna in #107, but with Nginx and PHP-FPM 7.x with Drupal 8.4+
Comment #112
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commented@lightweight: I wrote a blog post on how to configure Nginx to avoid this and other similar potential pitfalls in Drupal 8:
https://pantheon.io/blog/update-your-nginx-config-drupal-8
Comment #114
prlw1 CreditAttribution: prlw1 commentedJust saw this with drupal 8.6.4, php 7.2.12, nginx 1.15.6. Problem is, I already have
in my nginx.conf. That looks the same as in the blog post...
Just for the record:
Fixed by brute force:
Comment #117
Gorf CreditAttribution: Gorf commentedI wasn't sure if I should update this bug or not but I am getting this error on 8.9.1, MySQL backend and PHP 7.3.11 using php-fpm behind Nginx.
if I click on the link for error logs I get this output:
Comment #118
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commented@Gorf: Please see item #2 in my blog post: https://pantheon.io/blog/update-your-nginx-config-drupal-8
Comment #123
shenzhuxi CreditAttribution: shenzhuxi as a volunteer and commentedHi @greg.1.anderson, the patch only works with php built-in web server when ht.router.php is in the root directory.
https://www.drupal.org/project/drupal/issues/3341324 patch won't fix it.
For the URL issues through years, I feel that it may be better for Drupal to stop using weird dot position in URLs and only use dot for extension name.