The route user/password may not be accessible under certain circumstances, but the link to it is still available in the user login block. Going to provide an MR later today to fix this.

CommentFileSizeAuthor
#5 interdiff-3_5.txt567 bytesgauravvvv
#5 3227816-5.patch1.16 KBgauravvvv

Issue fork drupal-3227816

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

jurgenhaas created an issue. See original summary.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented
Title: User login block still shows link to passwored reset, even if access denied » User login block still shows link to password reset, even if access denied
Project: Lightweight Directory Access Protocol » Drupal core
Version: 8.x-4.x-dev » 9.2.x-dev
Component: Code » user system

Thinking about how to implement this, I came to the conclusion this belongs to core because that's the place where the link gets build and where we have to check access permission in the first place. It's not only the ldap module that may overwrite access to that route.

jurgenhaas opened merge request !1046

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented
Status: Active » Needs review
gauravvvv’s picture

gauravvvv commented
StatusFileSize
new 3227816-5.patch1.16 KB
new interdiff-3_5.txt567 bytes

Re-rolled patch #3, Fixed custom command failed. Attached interdiff for same.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented

@Gauravmahlawat thanks for adding the comma, I forgot about that.

Q: would you mind editing the MR instead of switching to patch? I guess this would be easier in the long run, if this issue remains open and discusssed for a while.

el7cosmos’s picture

el7cosmos
Primary language Indonesian
Location 🇮🇩 GMT+7
commented

Patches work for me.

I try to use #access in the render array to omit the if statement, but somehow item_list still renders the <li> only with an empty child.

joachim’s picture

joachim commented
Status: Needs review » Reviewed & tested by the community

RTBC based on @el7cosmos's review and a visual review from me.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented
Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests 
+++ b/core/modules/user/src/Plugin/Block/UserLoginBlock.php
@@ -126,16 +126,19 @@ public function build() {
+    if ($url->access()) {
+      $items['request_password'] = [
+        '#type' => 'link',
+        '#title' => $this->t('Reset your password'),
+        '#url' => $url,
+      ];
+    }

Removing the item from the render array can break contrib and custom code. Instead of the if set #access like so:
'#access' => $url->access(),
And yes we probably should use #access for the create access link but that is a separate issue which could be opened.

Also bugs need a test so we don't break this in the future. Thinking about the test you're going to need to add a helper module that alters the route because atm the route definition is

user.pass:
  path: '/user/password'
  defaults:
    _form: '\Drupal\user\Form\UserPasswordForm'
    _title: 'Reset your password'
  requirements:
    _access: 'TRUE'
  options:
    _maintenance_access: TRUE

So access is TRUE... so I'm interested in what

may not be accessible under certain circumstances,

actually means. I.e. what are the certain circumstances.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented

@alexpott yes, changing from an if statement to the #access control in the render array sounds great, but it causes the problem mentioned above in #7: the item-list template still outputs the li element in html and here is why:

  {%- if items -%}
    <{{ list_type }}{{ attributes }}>
      {%- for item in items -%}
        <li{{ item.attributes }}>{{ item.value }}</li>
      {%- endfor -%}
    </{{ list_type }}>
  {%- else -%}
    {{- empty -}}
  {%- endif -%}

The item for the password link still exists but its value is empty because of the #access set to FALSE. But that sounds like a different issue somewhere else.

what are the certain circumstances.

One of the circumstances I came across is the use of the ldap module where you can configure exclusive mode, i.e. the user accounts are exclusively controlled by the ldap backend and hence it doesn't make sense to allow users to reset their password in Drupal.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.1.10 (June 4, 2021) and Drupal 9.2.10 (November 24, 2021) were the last bugfix releases of those minor version series. Drupal 9 bug reports should be targeted for the 9.3.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.