Contrib.social

The coffee doesn't work with multilanguage, multidomain setup

Open on Drupal.org →
Created on 19 January 2024, 11 months ago

Problem/Motivation

We are experiencing a significant issue on our multi-domain, multi-language Drupal site, where each domain provides content in a different language. The administration interface is configured to use a fixed language associated with the main domain.

This configuration leads to a unique challenge when users on a secondary domain (e.g., en.site.com) try to use the Coffee module. The Coffee module attempts to make a cross-origin request from the secondary domain (en.site.com) to the main domain (site.com) and by default, it fails with CORS warnings in browser.

Under normal circumstances, configuring the CORS policy would resolve such issues. We have applied the necessary CORS settings using the cors.config section of services.yml file, specifying allowed headers, methods, and origins. This setup successfully eliminated CORS warnings in the browser. However, we encountered a problem with the https://site.com/admin/coffee/get-data request, which consistently resulted in a 403 error.

As a result, the Coffee module's popup on en.site.com displays incorrect content. Instead of the expected JSON structure, it shows HTML content with an error message.

To address this, we modified the cookie_samesite policy to "None" and changing cookie domain to common root, hoping it would allow cookies to be included in cross-origin requests. Despite this change, the issue persisted: the XHR call made by the Coffee module did not include cookies.

Further investigation revealed that the $.ajax call in coffee.js lacks the "withCredentials" flag. Upon adding this flag to the Coffee module's AJAX configuration, the issue was resolved, allowing the proper inclusion of cookies in the cross-origin request and preventing the 403 error.

Steps to reproduce

  1. Set up a multi-language installation of the site using Polish and English languages.
  2. Configure the interface language detection to use account settings.
  3. Set up content language detection based on the URL (domains). Prepare the domains en.site.com (for English) and site.com (for Polish).
  4. Attempt to use the Coffee module at en.site.com (this should result in a failure).
  5. Configure the site to support CORS: set cookie_domain to ".site.com", cookie_samesite to "None". Enable cors.config and configure its section with allowedHeaders, allowedMethods, and allowedOrigins set to all ('*'), and supportCredentials to true.
  6. Try using Coffee on en.site.com again (this will still result in a failure).

Proposed resolution

Simply modify the $.ajax function in coffee.js to fetch content from admin/coffee/get-data. Add xhrFields and set withCredentials to true in the options array.

Remaining tasks

  • Optionally, it may be beneficial to update project documentation / readme how to setup it for provided setup.
  • Evaluate, if it's an security risk (as we allow cross site requests).

User interface changes

No changes

API changes

No changes

Data model changes

No changes

🐛 Bug report
Status

Active

Version

1.0

Component

Code

Created by

🇵🇱Poland jsobiecki Wroclaw

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

Merge Requests

Comments & Activities

  • Issue created by @jsobiecki
  • Merge request !9#3415987 - fixed missing credentials in XHR call in cross domain setup. → (Open) created by jsobiecki
  • Issue was unassigned.
  • Status changed to Needs review 11 months ago
  • Comment 11 months ago →
    🇵🇱Poland jsobiecki Wroclaw

    The MR includes simple fix. The fix assumes

    1. CORS requests allowed between en.site.com and site.com
    2. Cookie has samesite: None and cookie_domain is ".site.com"

  • Status changed to Postponed: needs info about 1 month ago
  • Comment about 1 month ago →
    🇫🇷France dqd London | N.Y.C | Paris | Hamburg | Berlin

    Thanks for the report and work on this +1! Can you please re-test without the patch if this issue still exist? Reason is that this behavior has been reported elsewhere and stated that it is gone lately over here: 📌 Automated Drupal 11 compatibility fixes for coffee RTBC Also, in case if still required, we maybe need a MR in sync with this issue branch over there to get it added quickly to the Drupal 11 ready commit.

  • Comment about 1 month ago →
    🇵🇱Poland jsobiecki Wroclaw

    Hello @dqd,

    I re-created an empty, Drupal test site with similar setup (two domains, domain-based language detection).

    For testing, I'm using the dev version of the module.

    My results:

    "Vanilla" dev version - problem persists; the get-data endpoint returns a 403 error, and no suggestions appear in the coffee widget.
    "Vanilla" dev version with automatic D11 fixes patch (https://git.drupalcode.org/project/coffee/-/merge_requests/15.diff ) - problem persists; the get-data endpoint still returns a 403 error, and there are no suggestions.
    However, "Vanilla" dev version with automatic D11 fixes and the patch from this issue apply cleanly, and the problem is solved; the widget works as expected.

    As a bottom line, the problem still exists, but the patches apply cleanly and fix the reported issues. The issue was detected on a really "clean" installation of Drupal 10.

  • Comment about 1 month ago →
    🇵🇱Poland jsobiecki Wroclaw
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024