magento / magento/magento2

Login-As-Customer and Varnish conflict

Open
#39,147 20 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Area: Cache Component: User Issue: Confirmed Priority: P3 Progress: ready for dev Reported on 2.4.6-p6 Reproduced on 2.4.x Triage: Dev.Experience
Dominant language
PHP
Stars
12.2k
Forks
9.4k
PR merge metrics
No merged PRs in 30d

Description

### 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._
- [X] 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”._

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the Login-As-Customer module's GET /loginascustomer/login/index/ entry point and inspect the response headers when Varnish is enabled. Reproduce the login flow with cached and bypassed requests; done means the response prevents caching and the customer session is consistently recognized.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, php
Domain
backend, performance
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.