"Source path has to start with a slash" exception when hitting path prefixed with index.php with RequestPath condition

have this issue also v8.6.5

I am getting the same error on the same page in 8.7.8.

Patch is attached.

Hello, I have the same issue on 8.8.4. #4 patch fix the error, and display the following warning : "Warning: array_key_exists(): The first argument should be either a string or an integer in Drupal\Core\Path\AliasWhitelist->get() (line 120 of core/lib/Drupal/Core/Path/AliasWhitelist.php)."

Hi,

This patch is for drupal 8.7.x version and it also covers the issue mentioned in comment #7

Patch #8 fixed issue on Drupal 8.9.0.

Btw haven't faced this issue on version 8.8.5.

Added credit for drupert55 based on the report and follow up from #2763953: Certain characters in a site name lead to InvalidArgumentException: "Source path has to start with a slash." when Drupal installed in a subdirectory now marked as a duplicate.

Adding ml1 and haseebjamal as credited too.

Also noting that two reporters on #2763953: Certain characters in a site name lead to InvalidArgumentException: "Source path has to start with a slash." when Drupal installed in a subdirectory had this problem when there were special characters in their directory name, and were able to resolve it by removing those. Another user reported it whenever they had a port number appended to the URL.

Using Drupal 9.0.3, patches not working,
InvalidArgumentException: Source path has to start with a slash. in Drupal\path_alias\AliasManager->getAliasByPath() (line 189 of core/modules/path_alias/src/AliasManager.php).

In my case it is not caused by special characters in their directory name.

[EDIT] I had unchecked (on purpose) the permission "View published content" for anonymous users.
For anonymous users, for the front page this resulted in this error, for other pages it showed the expected 'Access denied'.

I couldn't reproduce this in the default installation, but I am getting the same error when there is a block with request_path condition.

Updated Steps to reproduce accordingly.

Related: #3167426: CurrentPathStack::getPath should always return a path with leading slashes, #2707991: Misleading error: "InvalidArgumentException: Source path has to start with a slash." when user cannot access the front page

Test only patch for #17.

I am not sure if this issue aims to cover more cases than I encountered in #17.

For that reason, I moved the patches/updates to #3167426: CurrentPathStack::getPath should always return a path with leading slashes.

I'm still seeing this a lot in the recent log messages with Drupal 9.0.7. In my case, it looks like stupid bots trying a bunch of random URLs. I can easily reproduce the error by going to /index.php.php on the website.

I don't understand why this should generate a PHP (500) error instead of just a not found (404) error.

I have the same issue on Drupal 9.0.6 core version with missing front: page in system.site.yml because we have different front page per environment (LOCAL/DEMO/DEV/TEST/STAGE/PROD). And sometimes front page setting is missing which is not an error.

I found a solution in Drupal/system/Form/SiteInformationForm->buildForm() line 125:

- $front_page = $site_config->get('page.front') != '/user/login' ? $this->aliasManager->getAliasByPath($site_config->get('page.front')) : '';

+ $front_page = ($site_config->get('page.front') != '/user/login' && !empty($site_config->get('page.front'))) ? $this->aliasManager->getAliasByPath($site_config->get('page.front')) : '';

I'm just adding && !empty($site_config->get('page.front') which resolve the issue in my case.

I post the patch of #23.
I already tested on the both of D8.9.x and D9.0.x branch and it is working fine.

Applied the patch from #24 and tested successfully. Thanks for the fix @vuil!

I set the issue status to RTBC.

I have used patch #24 and see error:
InvalidArgumentException: Source path https://example.lndo.site/catalog-search?sort_bef_combine=published_date_ASC&f[0]=tracks:242&title= has to start with a slash. in Drupal\Core\Path\AliasManager->getAliasByPath() (line 229 of /app/web/core/lib/Drupal/Core/Path/AliasManager.php).

Looks like it's another string in the same file

This issue appears to have changed direction in between #18 and #22 and there's no tests in the latest patch. Also the patch in #24 doesn't apply to 9.2.x and doesn't solve the steps to reproduce in the issue summary.

That said, I think we should be triggering a 404 if someone hits index.php.php... as we should for index.phpbbhgfbg which also produces the same error.

I think the problem in #24 is a separate issue. FWIW if the system.site:page.front setting is empty then your frontpage will be a 404 and if we do the fix in #24 and then goto the site information page and press save it'll change the empty setting back to user/login... so that needs more work.

Oh interesting it seems now the first bug this issue fix is now #3167426: CurrentPathStack::getPath should always return a path with leading slashes so this issue can become about the SystemInformationForm :) I think this is a normal bug because via the UI it is impossible to set the config value to an empty string.

If you go to /index.php5 or /index.php.htm, index.phpblahblahblah or /index.php{anything without a leading slash}, it will throw this error from line 229 of AliasManager.php

InvalidArgumentException: Source path {whatever} has to start with a slash. in Drupal\Core\Path\AliasManager->getAliasByPath() (line 229 of core/lib/Drupal/Core/Path/AliasManager.php).

Updated patch, also you need to use another patch from here to fix the warning #3215098: AliasManager->getAliasByPath('//') PHP Warning

Drupal Version

9.3.13

Domain module version

8.x-1.0-beta6

Expected Behavior

Navigate to https://mydomain.com/node/xxx to view or edit node when this node domain source field is filled

Actual Behavior

I got an error :
InvalidArgumentException: Source path http://mydomain.com/node/1219/edit has to start with a slash. in Drupal\path_alias\AliasManager->getAliasByPath() (line 185 of core\modules\path_alias\src\AliasManager.php).

Steps to reproduce

• Create a node
• Assign a domain source to this node
• Navigate either to /node/[nid] or /node/[nid]/edit

Note that no error occurs if node domain source field is null.
Applied https://www.drupal.org/files/issues/2022-02-20/3043779-31.patch with no luck.

Drupal Version

9.3.13

Domain module version

8.x-1.0-beta6

Expected Behavior

Navigate to https://mydomain.com/node/xxx to view or edit node when this node domain source field is filled

Actual Behavior

I got an error :
InvalidArgumentException: Source path http://mydomain.com/node/1219/edit has to start with a slash. in Drupal\path_alias\AliasManager->getAliasByPath() (line 185 of core\modules\path_alias\src\AliasManager.php).

Steps to reproduce

• Create a node
• Assign a domain source to this node
• Navigate either to /node/[nid] or /node/[nid]/edit

Note that no error occurs if node domain source field is null.
Applied https://www.drupal.org/files/issues/2022-02-20/3043779-31.patch with no luck.

Not sure if we still need an issue summary update, the steps are fairly clear.

Here's one approach with a test only patch. The test fails still because of another issue with the fix but it gets us closer...

Updated IS, removed irrelevant tags.

Fix for Warning: Undefined array key 1 template_preprocess_html()

Derp, should be a 404.

This is about the RequestPath condition.

The problem is more pervasive than this. If you visit /index.php5 (as mentioned in #30), something takes everything after "index.php" as the path alias, and you end up in PathAlias.php with the path part set to "5" which throws an error, and #3215098: AliasManager->getAliasByPath('//') PHP Warning does not fix that.

I don't understand why the test passes but it doesn't work in my browser.

In my browser (or curl)

$ curl -SIl https://mysite.ddev.site/index.php5
HTTP/1.1 500 500 Service unavailable (with message)
Server: nginx/1.20.1
Date: Fri, 03 Feb 2023 18:37:53 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Cache-Control: must-revalidate, no-cache, private
X-UA-Compatible: IE=edge
Content-language: en
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Expires: Sun, 19 Nov 1978 05:00:00 GMT
X-Generator: Drupal 9 (https://www.drupal.org)

I kicked the test bot to test it here, and this test passes (ignore the unrelated test failures). So I ran it locally and it also passes:

$ phpunit modules/block/tests/src/Functional/BlockTest.php
PHPUnit 9.6.0 by Sebastian Bergmann and contributors.

Warning:       Your XML configuration validates against a deprecated schema.
Suggestion:    Migrate your XML configuration using "--migrate-configuration"!

Testing Drupal\Tests\block\Functional\BlockTest
..............                                                    14 / 14 (100%)

Time: 00:46.416, Memory: 6.00 MB

OK (14 tests, 247 assertions)

HTML output was generated

Sorry, I've isolated my particular problem to another module, so I'm restoring this to "needs review." Since this is a different (but similar problem) I'm not actually commenting on this patch.

This issue is reproducible in Drupal 10.1 also.

I have tried a patch for this issue in Drupal 10.1, this may resolved the mentioned problem. kindly review.

@priya.chat did you miss the previous patches? There's already ongoing work for this issue, with tests etc (see #46)

If that doesn't work for you, would you mind explaining what your solution does differently?

Hi @acbramley, I have tried previous patched for Drupal 10.1 , but didin't worked for me so I have given a try to first check if the path is valid for which we are validating the "/" value then apply the other checks. Thanks.

@priya.chat can you provide steps for how it's failing for you?

Can't drop test coverage though.

Hi @smustgrave , I have applied patch on #33 and tried to access /index.php5 or /index.php.php on Drupal 10.1.x , getting error below

InvalidArgumentException: Source path .php has to start with a slash. in Drupal\path_alias\AliasManager->getAliasByPath() (line 185 of /core/modules/path_alias/src/AliasManager.php).

Kindly suggest, if I am following any wrong step to reproduce this issue.

In my particular case, a visitor went to mysite.com/index.php) which causes a white screen error. #46 didn't work for me but #56 resolved the issue.

Rerolled #56 for 10.3. Applies cleanly and addresses the issue as described by making the change in path auto module for requiring a slash.

Reading the thread again, I've moved the initial test from #39 into the patch from #56 rerolled in #60 into this patch, #61.

Patch in #61 worked well for me on 10.3. Thanks!

Edit:

The last patch couldn't be applied to Drupal 10.3.9.

Here is a reroll.

When updating to Drupal 11.1.3 while this patch is installed, clearing cache for the first time (the first of our post-deployment steps), the following error happens. Removing the patch allows cache to be cleared, and it can be added back. I think a check for an empty or unset whitelist will fix this. If so, I'll update the patch.

Error: Call to a member function get() on null in /var/www/html/docroot/core/modules/path_alias/src/AliasManager.php on line 149 #0 /var/www/html/docroot/core/modules/path_alias/src/PathProcessor/AliasPathProcessor.php(47): Drupal\path_alias\AliasManager->getAliasByPath()
#1 /var/www/html/docroot/core/lib/Drupal/Core/PathProcessor/PathProcessorManager.php(108): Drupal\path_alias\PathProcessor\AliasPathProcessor->processOutbound()
#2 /var/www/html/docroot/core/lib/Drupal/Core/Routing/UrlGenerator.php(392): Drupal\Core\PathProcessor\PathProcessorManager->processOutbound()
#3 /var/www/html/docroot/core/lib/Drupal/Core/Routing/UrlGenerator.php(294): Drupal\Core\Routing\UrlGenerator->processPath()
#4 /var/www/html/docroot/core/lib/Drupal/Core/Render/MetadataBubblingUrlGenerator.php(105): Drupal\Core\Routing\UrlGenerator->generateFromRoute()
#5 /var/www/html/docroot/core/lib/Drupal/Core/Url.php(769): Drupal\Core\Render\MetadataBubblingUrlGenerator->generateFromRoute()
#6 /var/www/html/docroot/modules/contrib/webform/src/WebformHelpManager.php(1613): Drupal\Core\Url->toString()
#7 /var/www/html/docroot/modules/contrib/webform/src/WebformHelpManager.php(146): Drupal\webform\WebformHelpManager->initHelp()
#8 /var/www/html/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(259): Drupal\webform\WebformHelpManager->__construct()
#9 /var/www/html/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(177): Drupal\Component\DependencyInjection\Container->createService()
#10 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(289): Drupal\Component\DependencyInjection\Container->get()
#11 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(253): Drush\Runtime\LegacyServiceInstantiator->resolveFromContainer()
#12 [internal function]: Drush\Runtime\LegacyServiceInstantiator->resolveArgument()
#13 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(223): array_map()
#14 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(193): Drush\Runtime\LegacyServiceInstantiator->resolveArguments()
#15 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(167): Drush\Runtime\LegacyServiceInstantiator->instantiateObject()
#16 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(117): Drush\Runtime\LegacyServiceInstantiator->create()
#17 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(54): Drush\Runtime\LegacyServiceInstantiator->instantiateServices()
#18 /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php(242): Drush\Runtime\LegacyServiceInstantiator->loadServiceFiles()
#19 /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php(218): Drush\Boot\DrupalBoot8->addDrupalModuleDrushCommands()
#20 /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php(211): Drush\Boot\DrupalBoot8->bootstrapDrupalFull()
#21 /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php(397): Drush\Boot\BootstrapManager->doBootstrap()
#22 /var/www/html/vendor/drush/drush/src/Application.php(219): Drush\Boot\BootstrapManager->bootstrapMax()
#23 /var/www/html/vendor/drush/drush/src/Application.php(185): Drush\Application->bootstrapAndFind()
#24 /var/www/html/vendor/symfony/console/Application.php(284): Drush\Application->find()
#25 /var/www/html/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRun()
#26 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#27 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#28 /var/www/html/vendor/drush/drush/drush.php(140): Drush\Runtime\Runtime->run()
#29 /var/www/html/vendor/bin/drush.php(119): include('...')
#30 {main}
Error: Call to a member function get() on null in Drupal\path_alias\AliasManager->getAliasByPath() (line 149 of /var/www/html/docroot/core/modules/path_alias/src/AliasManager.php).
 [warning] Drush command terminated abnormally.
Failed to run drush cr: exit status 1

$whitelist was changed to $pathPrefixes in Drupal 11.1.0

https://git.drupalcode.org/project/drupal/-/commit/27948b069b1be0be6062b...

Here is an updated patch for Drupal 11.1+.

This needs to be rolled onto an MR.

I am running into this being flagged by Invicti/Netsparker scan because they try to hit nonsensical pages like

• /index.php.
• /index.php.?hTTp://r87.com/n
• /index.phpI-dont-exist
• /index.php.php/some/path

And Invicti objects to getting a 500 response instead of a more appropriate 404. I agree with desoi, acbramley and alexpott who suggested this should be a 404. Sites with a 500 error look broken and it should not be this easy to make a Drupal site look broken.

alexpott indicated there was a possible problem with 404-ing in this case. I wonder if instead of trying to handle this at the php level and replacing the thrown exception with a 404, if it would be cleaner to have a well crafted rule in .htaccess that handles the non slash characters after `index.php`

I created a new branch and PR ^^ for an .htaccess approach to the problem. It is simpler, and since most sites customize their .htaccess anyway, this would allow them to alter it without really needing to patch core.

While the Tugboat is available, this url should return fine
https://mr11806-gs7qqwaidh3locbz5vsd5vt5golwwmyn.tugboatqa.com/index.php

And this one should result in 404
https://mr11806-gs7qqwaidh3locbz5vsd5vt5golwwmyn.tugboatqa.com/index.phpboo

It could be useful to potentially have both the php and htaccess fixes.

I also ran into this, with #3530291: Warning logged: Source path aut has to start with a slash.
In this case it could be a module using the API wrong, what triggers the exception.

On Drupal 10.5 this also occurs if someone just adds an extra / to the homepage, for example https://www.example.gov// which the htaccess route (3043779-htaccess-no-php-danglers) doesn't cover that situation.

And the other patch (3043779-source-path-has-11.x) results in a new error

The website encountered an unexpected error. Try again later.

Error: Call to a member function get() on null in Drupal\path_alias\AliasManager->getAliasByPath() (line 199 of core/modules/path_alias/src/AliasManager.php).
Drupal\protected_pages\EventSubscriber\ProtectedPagesSubscriber->checkProtectedPage(Object, 'kernel.response', Object)

because pathPrefixes wouldn't exist in 10.5 https://git.drupalcode.org/search?search=pathPrefixes&nav_source=navbar&...

Why can't we just do something simpler like this?

  public function getAliasByPath($path, $langcode = NULL) {
    // Normalize the path: handle empty/null paths and ensure proper formatting.
    if (empty($path) || $path === '') {
      $path = '/';
    }

    // Ensure the path starts with a slash. If it doesn't, prepend one.
    if (!str_starts_with($path, '/')) {
      $path = '/' . $path;
    }

That seems to fix things that I tested from the comments above

• https://www.example.gov//
• /index.php5
• /index.php.
• /index.php.?hTTp://r87.com/n
• /index.phpI-dont-exist
• /index.php.php/some/path

I have this issue also, i have attached a patch for Drupal 10.4.7. Just for test purposes.

I have updated the previous patch for Drupal 10.5

I can't reproduce #75 and I'm not sure I agree with #76 that the changes to AliasManager are simpler. This specific bug report is coming from the RequestPath condition plugin.

I've opened an MR with my preferred solution (from back in #46)

I'm going to close the MR for htaccess because while that may fix things for sites on Apache, it won't do anything for sites running on other technologies e.g Nginx. Also hiding patches.

@acbramley You said #75 you can't reproduce, but here is a link to try https://www.justice.vic.gov.au// its easy way to spot drupal sites now

I was trying to reproduce this issue in PHP Test using below code, error is visible on ui. but my test is not failing. ideally it should show error while running tests. if I don't apply any solution.

protected function testrandomurl(): void {
    $this->drupalGet('/index.php' . $this->randomMachineName());
    $this->assertSession()->statusCodeEquals(404);
  }

@anmol singh we have test coverage in the MR see https://git.drupalcode.org/project/drupal/-/merge_requests/13580/diffs#d...

1- @acbramley it's not about this MR (https://git.drupalcode.org/project/drupal/-/merge_requests/13580/diffs#d...) I am applying patch https://www.drupal.org/project/drupal/issues/3043779#comment-16221793 which is fixing my Problem. for this I am writing my own PHP Tests which is not failing.

2- This MR(https://git.drupalcode.org/project/drupal/-/merge_requests/13580/diffs#d...) is no need for me because here your issue is fixed in RequestPath.php
but i am getting error on AliasManager.php for this you have this MR(https://git.drupalcode.org/project/drupal/-/merge_requests/11348/diffs) but there is no PHP Test.

looks like this index.php is being abused (from my access log from some soviet hackers):

/index.php/node/

Hi @acbramley
when I am using this MR (https://git.drupalcode.org/project/drupal/-/merge_requests/11348/diffs) it is fixing index.php77 issue but i am still seeing Warning: Undefined array key 1 template_preprocess_html(). why this warning is not addressed in this MR as well. I think that should be fixed in this as well(https://git.drupalcode.org/project/drupal/-/merge_requests/11348/diffs).

IMP!
I've updated symfony/http-foundation from v6.4.26 to v6.4.29 and now everything is working fine. but what fixed in symfony/http-foundation.

Now i think we can close this issue as fixed in symfony/http-foundation.

I was seeing this same problem when hitting a URL like /index.php3 on my site... but today I've updated symfony/http-foundation from v6.4.26 to v6.4.29 and now everything is working correctly.

Wondering if anyone else is experiencing something similar?

So perhaps the bug is fixed via symfony/http-foundation update (#3557393: Update Symfony to 7.3.7 / 6.4.29), which adds the leading / already?

@anmol singh my MR is https://git.drupalcode.org/project/drupal/-/merge_requests/13580/diffs, I've hidden the other one now.

@acbramley I think this issue should be closed as mentioned above in comment #90 its already fixed by upgrading symfony/http-foundation from v6.4.26 to v6.4.29

Core now uses "symfony/http-foundation": "^7.4" so can we confirm if this is still a bug?

I'm unable to reproduce it on a client site on 11.3, not sure how the library bump fixed it but I don't even hit a debugger in the RequestPath condition plugin anymore on index.php with some random characters after it.

Since there's been no follow up and last few comments mention not being able to reproduce this going to close out.