proxy logs "no user in context" at error level for every data gateway download
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
Research direction
Start with services/proxy/pkg/middleware/create_home.go, especially shouldServe and the branch that logs when the request context has no user. Trace how the /data route reaches this middleware and run the relevant proxy middleware tests. Done when these downloads pass through without an error-level “no user in context” log, while requests that need home creation still behave correctly.
Written by the indexing model from the issue text.
Description
Describe the bug
The proxy logs {"level":"error","service":"proxy","message":"no user in context"} for every file download that goes through the data gateway. Nothing fails, but on a busy instance these lines make up most of the error log.
Cause
services/proxy/pkg/middleware/create_home.go runs for any request that carries an x-access-token header (shouldServe). When there is no user in the request context, it logs at error level and passes the request on.
reva's internal download requests to the data gateway go through the proxy's /data route, which is unprotected. reva's HTTP client (rhttp.NewRequest) copies the caller's token into x-access-token, but no authenticator resolves a user on that route. So create_home sees a token without a user, logs the error, and the download carries on normally.
Steps to reproduce
curl -H 'x-access-token: x' http://127.0.0.1:9200/data/anything
The proxy logs one no user in context error (the request is then rejected by the data gateway, as expected). Real downloads (sync clients, the web UI, search content extraction) log one each. On our 8.2.0 instance that came to 200–800 a day, with peaks on re-indexing days.
Expected behaviour
There is no home to create for these requests, so the middleware should pass them on without an error-level log.
- Dominant language
- Go
- Stars
- 2.1k
- Forks
- 277
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 126
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from owncloud/ocis
-
Type:Bug
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Fake OIDC data created by auth-app missing displayName claimPossibly taken A pull request linked to this issue is open or already merged. OpenType:Bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
owncloud/ocis#13032 · 6 comments ·
Maintainers usually reply within 1 day
-
chore
Difficulty 1/5 Under an hour Newbie friendliness 72/100
owncloud/ocis#12524 · 3 comments ·
Maintainers usually reply within 1 day
-
QA:team
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
owncloud/ocis#11990 · 1 comment ·
Maintainers usually reply within 1 day
-
Type:Bug
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
owncloud/ocis#11757 · 2 comments ·
Maintainers usually reply within 1 day
Similar issues
-
raised-by:worker
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
medici-finance/assay#2486 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
openimsdk/openim-sdk-core#1127 ·
-
github_actions
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Hochfrequenz/aibap.mcp#578 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
mvanhorn/cli-printing-press#4980 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
lenaxia/LLMSafeSpaces#1644 · 3 comments · 1 reaction ·
Maintainers usually reply within 1 day