"To log in to this site, your browser must accept cookies from the domain" error message displayed when user goes back and reload the page

Created on 30 October 2023, about 1 year ago

Problem/Motivation

The message "To log in to this site, your browser must accept cookies from the domain" is displayed to the user when they use "Back" button and refresh the page.

Steps to reproduce

1. Login with any user
2. Log out
3. Click to go back (Back button of the browser)
4. Reload the page
5. See the message

The message is quite confusing for the user when they perform the steps above as it doesn't make sense.

Is this by design?

🐛 Bug report
Status

Active

Version

10.1

Component
User system 

Last updated 1 day ago

Created by

🇧🇷Brazil carolpettirossi Campinas - SP

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @carolpettirossi
  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    The steps to reproduce sound a lot like what happens with cookies off when you try to login

    So yes this might be by design

  • 🇨🇦Canada omegaqa1234

    Was this issue ever solved?

  • Status changed to Needs review 9 months ago
  • 🇮🇳India prashant.c Dharamshala

    In our situation, we encountered this error after updating the site to version 9.5. We had also installed the Automated Logout module. Based on discussions here, it seemed this module might be the cause:

    However, we applied a patch to the Drupal core, and currently, everything appears to be functioning well. I've attached the patch for community review. https://www.drupal.org/forum/support/installing-drupal/2023-02-13/to-log... .

    However, we patched the Drupal core and as of now seems to be working fine. Attaching the patch for community review.

    Thanks

  • Status changed to Needs work 9 months ago
  • The Needs Review Queue Bot tested this issue.

    While you are making the above changes, we recommend that you convert this patch to a merge request . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.2 & MySQL 8 (--ignore-platfrom-reqs)
    last update 7 months ago
    29,716 pass, 2 fail
  • 🇫🇷France frondeau Nantes, FRANCE

    Hello,
    I'm encountering the same issue on la site.localhot with Drupal 10.2.6, on Google Chrome, as my third part cookies are configured in the browser as not alloed in the private session only.
    The current path is well applied on my local and I can log, but the /admin path is not allowed while my profile is an administrator role.
    So please take care: this patch can't solve all the cases.

    FYI: I can log on Firefox.

    So it's a strange issue, maybe encontered only on google chrome, isn't it ?

    Regards

  • Merge request !8207Added uid check → (Open) created by prashant.c
  • Status changed to Needs review 7 months ago
  • 🇮🇳India prashant.c Dharamshala
  • Pipeline finished with Failed
    7 months ago
    Total: 506s
    #184662
  • Status changed to Needs work 7 months ago
  • 🇮🇳India sourabhjain

    I am facing the same issue with the Drupal 10.3 version so attaching the updated patch.

  • 🇮🇳India prashant.c Dharamshala

    @sourabhjain

    I think this patch file is unnecessary as the exact same code is in the MR already. I do not see any update in the patch file.

  • 🇮🇳India sourabhjain

    Hi @prashant
    Thanks for the confirmation.
    Actually I was facing an issue in my Drupal 10 code and the MR is related to the 11.x so I have created it for 10.3.x.
    I am not sure how we can use the MR code in the composer patches. Sorry for that.

  • 🇬🇧United Kingdom oily Greater London
  • 🇺🇦Ukraine losewn Lviv

    Error in samesite
    ini_set('session.cookie_samesite', 'None');

  • 🇮🇳India manojkumar_g

    Hi @losewn @sourabhjain
    I have added the line below to settings.php. Still, the error is not resolved. Whenever I try to log in to the Drupal site it's showing the below error.

    Drupal version is 10.3.0
    Error: To log in to this site, your browser must accept cookies from the domain

    Code added in settings.php:
    ini_set('session.cookie_samesite', 'None');

  • First commit to issue fork.
  • Pipeline finished with Failed
    11 days ago
    Total: 528s
    #366214
  • 🇨🇦Canada tame4tex

    This bug has also been causing us some grief. I have added a test for the bug using the steps to reproduce outlined in the issue summary.

    The bug can even be replicated by simply visiting user/login?check_logged_in=1 as an anonymous user.

    Where we have experienced the issue is users being redirected after login to a page that contains the check_logged_in, then for whatever reason they are logged out but they reload the page that contains the query parameter and the confusing and incorrect error message appears.

    I have reverted the previous fix in the merge request as it was causing the existing testCookiesNotAccepted() test to fail. If cookies are disabled then the session will never contain the 'uid' so the error message is not displaying when it should.

    As far as how to solve the issue, I can't think if a way to do so with the current query parameter approach without doing something hacky like setting the check_logged_in to a timestamp and then checking the time and only displaying the error if it is less than X seconds old.

    As an alternative to a query parameter, could we instead in use a kernal.request event listener and check if the request is for the user.login route using the POST method, indicating the user login form is being submitted, and display the error message if the session doesn't exist.

    I will work on this more tomorrow and see if that is a viable approach unless I get other feedback in the meantime.

  • Pipeline finished with Failed
    11 days ago
    Total: 2640s
    #366228
  • Pipeline finished with Failed
    11 days ago
    Total: 490s
    #366269
  • 🇬🇧United Kingdom oily Greater London

    Removed sleep(10) function from the Functional test. The test works the same without it.
    With a failing test in place, a code fix is now required.

  • 🇬🇧United Kingdom oily Greater London

    @tame4tex WRT #19, If there is an existing event listener that some code logic can be added to to fix this issue would be good. Creating a new event listener might be overkill and not sure if it could impact performance.

    This seems to be the code that controls the error message in the Cookie.php file:

      public function applies(Request $request) {
        $applies = $this->sessionConfiguration->hasSession($request);
        if (!$applies && $request->query->has('check_logged_in')) {
          $domain = ltrim(ini_get('session.cookie_domain'), '.') ?: $request->getHttpHost();
          $this->messenger->addMessage($this->t('To log in to this site, your browser must accept cookies from the domain %domain.', ['%domain' => $domain]), 'error');
        }
    

    It takes the Request object as a parameter. i.e. the Response event has not been dispatched yet.

    At line 118 in Cookie.php you have this:

      /**
       * Adds a query parameter to check successful log in redirect URL.
       *
       * @param \Symfony\Component\HttpKernel\Event\ResponseEvent $event
       *   The Event to process.
       */
      public function addCheckToUrl(ResponseEvent $event) {
        $response = $event->getResponse();
        if ($response instanceof RedirectResponse) {
          if ($event->getRequest()->getSession()->has('check_logged_in')) {
            $event->getRequest()->getSession()->remove('check_logged_in');
    ........
    ........
    

    This is an existing kernel event listener that listens to the Response event. The Response event precedes the sending of the response to the user-agent (browser). So manipulation of the response can be done prior to sending the response to the user-agent.

    1. A fix should be attempted using the existing event listener addCheckToUrl()
    2. If necessary the fix might add conditional logic to public function applies(Request $request)
    3. Failing 1. and 2. a new event listender can be added to Cookie.php. It could listen to the Response event, for example.
  • 🇨🇦Canada tame4tex

    Ah thanks for removing that @oily, it was cruft that I forgot to remove while I was testing possible solutions. Thanks also for the insight.

    Going to dig in now for an hour and see what I can come up with.

  • 🇬🇧United Kingdom oily Greater London
  • Pipeline finished with Failed
    10 days ago
    Total: 148s
    #367247
  • 🇨🇦Canada tame4tex

    So this turned out to be a challenging bug to fix!

    After reviewing the original issue ( 🐛 Login fails and no warning is issued if cookies are not enabled Fixed ) which added the code in the first place, I noted a few mentions of a double redirect approach to solve the original issue. I decided to attempt to implement that approach but only if the request contains the check_logged_in query parameter and there is no session for the request. So the extra redirects would only ever happen for users who have cookies disabled or happen to directly access a url with the check_logged_in query parameter when they are logged out. So it would rarely be experienced by regular users.

    This resulted in adding a new /user/verify-cookies page which does the checking for a cookie added to the response and displays an error message if cookies are disabled or redirects the user to their original request if cookies are enabled.

    Open to any feedback on the title and text displayed on this new page. I am also wondering if it should NOT be within the user module and instead in a more generic location given it could be used by other functionality or contrib modules that need to verify cookies are enabled.

    I also added this new page to robots.txt as it shouldn't be crawled.

    With the new approach I was unable to successfully test when cookies were disabled using the existing Functional UserLoginTest as cookies seem to be enabled after the POST request to the user login form. Therefore I switched it to a Functional Javascript test and modified the chrome options to ensure cookies were disabled.

    I have updated the Issue Summary with the proposed resolution.

    Ready for review and feedback

  • Pipeline finished with Failed
    10 days ago
    Total: 148s
    #367264
  • Pipeline finished with Failed
    10 days ago
    Total: 466s
    #367269
  • Pipeline finished with Success
    10 days ago
    Total: 5123s
    #367276
  • 🇬🇧United Kingdom oily Greater London

    I note that all tests in the pipeline are green since the last commits by @tame4tex. Manually running the 'test-only' test gives expected result.

    Test coverage is now in place. There is now a test that fails without the fix and passes with the fix applied.

    It would be interesting to find out if the fix in this issue fixes the related issue related issue 3255711 🐛 Log out show error message "... your browser must accept cookies ..." Needs work . Could then look at closing that issue along with this one.

  • 🇨🇦Canada tame4tex

    tame4tex changed the visibility of the branch 3397718-to-log-in-10.3.x to hidden.

  • 🇨🇦Canada tame4tex

    tame4tex changed the visibility of the branch 10.3.x to hidden.

  • 🇨🇦Canada tame4tex

    tame4tex changed the visibility of the branch 11.x to hidden.

  • Pipeline finished with Success
    8 days ago
    Total: 2607s
    #368601
Production build 0.71.5 2024