Skip to content

Login-As-Customer and Varnish conflict #39147

Open
@webloft

Description

@webloft

Preconditions and environment

We found out that Login-As-Customer attempt only works randomly with Varnish and there is a simple reason for that:

  • The VCL declares that GET/HEAD requests should filter Set-Cookie-headers:
if (beresp.ttl > 0s && (bereq.method == "GET" || bereq.method == "HEAD")) {
        unset beresp.http.set-cookie;
}
  • The Login-As-Customer module JS opens a GET /loginascustomer/login/index/?secret=*** request and resets the PHP session id
  • Resetting the PHP session id will issue a Set-Cookie-Header with the new session id
  • The cookie header will be ignored by Varnish
  • The login fails since the browser doesn't know the new session id and stills sends the old one

Steps to reproduce

Enable & configure Varnish and try to login as customer

Expected result

Login as customer session works.

Actual result

Login as customer MAY work.

If you are lucky, the session will be recognized - or not if Varnish delivers a cached version.

Additional information

The issue can be bypassed by configuring the VCL:

# Bypass shopping cart, checkout and search requests
if (req.url ~ "/customer" || req.url ~ "/checkout" || req.url ~ "/loginascustomer") {
        return (pass);
}

...

# validate if we need to cache it and prevent from setting cookie
if (beresp.ttl > 0s && (bereq.method == "GET" || bereq.method == "HEAD") && !(bereq.url ~ "/loginascustomer")) {
        unset beresp.http.set-cookie;
}

but should be done correctly by the module itself by sending a Cache-Control: private header.

Release note

No response

Triage and priority

  • Severity: S0 - Affects critical data or functionality and leaves users without workaround.
  • Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
  • Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
  • Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
  • Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area: AccountComponent: UserIssue: ConfirmedGate 3 Passed. Manual verification of the issue completed. Issue is confirmedPriority: P3May be fixed according to the position in the backlog.Progress: ready for devReported on 2.4.6-p6Indicates original Magento version for the Issue report.Reproduced on 2.4.xThe issue has been reproduced on latest 2.4-develop branchTriage: Dev.ExperienceIssue related to Developer Experience and needs help with Triage to Confirm or Reject it

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions