Problem/Motivation

I'm running into a strange issue where I can't access the /user/login page on an inactive domain even though /user/login is whitelisted at /admin/config/domain/settings. I always get redirected to the default domain's login page.

I dug into the code a little bit and set a breakpoint in Drupal\domain\Access\DomainAccessCheck::checkPath().

public function checkPath($path) {
  $allowed_paths = $this->configFactory->get('domain.settings')->get('login_paths');
  return !$this->pathMatcher->matchPath($path, $allowed_paths); // BREAKPOINT HERE
}

Interestingly, I found that $path, which is the result of Symfony\Component\Routing\Route::getPath(), seems to always return a path without the preceding "/", e.g it returns user/login rather than /user/login. I thought I might've misconfigured, but I checked domain's default configuration, and it sets the user login and password reset paths with the preceding slash, i.e. I'm using the default configuration.

No problem, though, it's simple enough to fix, so I updated my configuration to use user/login without the preceding slash. Surprisingly, this still doesn't work! However, now, instead of being redirected to the default domain's login page, I see "You're not authorized...", i.e. a 403, and I remain at the url for my inactive domain's user login page. Bizarre!

Out of curiosity, I tried whitelisting /user/login and user/login and, amazingly, I can access the /user/login form fine and login with no problems. It seems that I can only access any of these paths after whitelisting it with and without the preceding slash.

Steps to reproduce

  1. Create a default domain
  2. Create another domain, e.g. other.example.com, but set it as inactive
  3. Attempt to access other.exmaple/com/user/login

I'm using Domain 8.x-1.0-beta2 with Drupal 8.9.x.

Proposed Resolution

No clue.

Issue fork domain-3176457

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

sonfd created an issue. See original summary.

sonfd’s picture

sonfd
he/they
Location Portland, ME
commented
Issue summary: View changes
agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

That's odd. We account for this logic in domain/tests/src/Functional/DomainInactiveTest.php

Perhaps that test is wrong, because a redirect would return a 200 -- though that seems wrong from a testing standpoint, the test runner should return 301 or 302.

Here's the relevant part of the test:

    // Disable the domain and test for redirect.
    $domain->disable();
    $default = \Drupal::entityTypeManager()->getStorage('domain')->loadDefaultDomain();
    // Our postSave() cache tag clear should allow this to work properly.
    $this->drupalGet($domain->getPath());

    $this->assertFalse($domain->status(), 'Tested domain is set to inactive.');
    $this->assertTrue($default->getPath() == $this->getUrl(), 'Redirected an inactive domain to the default domain.');

    // Check to see if the user can login.
    $url = $domain->getPath() . 'user/login';
    $this->drupalGet($url);
    $this->assertResponse(200, 'Request to login on inactive domain allowed.');
    // Check to see if the user can reset password.
    $url = $domain->getPath() . 'user/password';
    $this->drupalGet($url);
    $this->assertResponse(200, 'Request to reset password on inactive domain allowed.');

I wonder if any of your server parameters matter here, too?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

It would be helpful if you could run that test on your system.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Postponed (maintainer needs more info)
agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)
ded’s picture

ded commented
Version: 8.x-1.0-beta2 » 2.0.0-beta2
Status: Closed (cannot reproduce) » Active

I have run into the same issue with 2.0.0-beta2. I changed the whitelisted paths to not start with a slash so 

user/login
user/password

and then they were accessible.

mably made their first commit to this issue’s fork.

mably opened merge request !193

mably’s picture

mably commented
Version: 2.0.0-beta2 » 2.0.x-dev
Status: Active » Needs review

Hi @sonfd @ded, could you give a try to this issue's MR please?

Remember that if you're on a multilang site using language prefixes, you might have to add the following to the list of allowed paths:

*/user/login
*/user/password

If somebody knows why this slash trimming was done in the first place, don't hesitate to tell us why. Related commit.

mably’s picture

mably commented
Issue tags: +next-release
mably’s picture

mably commented

I confirm that this fix should be merged: the functional tests were not working correctly. They have been fixed.

$this->assertSession()->statusCodeEquals(200);

Has been replaced by:

$this->assertEquals($url, $this->getUrl());

The first assertion above was always true, even after a redirection had occurred.

Please review.

ben.hamelin’s picture

ben.hamelin
he/him
Primary language English
Location Adirondack Mountains, NY
commented
Status: Needs review » Reviewed & tested by the community

@mably Did a quick code review, everything looked good.
Patch applied to 2.x-dev.
Confirmed with inactive domain that I could load the /user/login page.

I think this is ready to go.

mably’s picture

mably commented

Thanks @ben.hamelin!

  • mably committed 5263a1d4 on 2.0.x 
    Issue #3176457 by sonfd, ded, mably: Can't access whitelisted paths for...
mably’s picture

mably commented
Status: Reviewed & tested by the community » Fixed
Issue tags: -next-release

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.