Self-hosted version requiring login multiple times

[gdcmarinho]

Describe the bug
The app requires login repetitive times by no reason. No matter how many times I submit my login credentials.

To Reproduce
Steps to reproduce the behavior:

1. Just open the app and wait a few seconds.

Expected behavior
No require login each 3 or 5 seconds.

Screenshots

Desktop (please complete the following information):

• OS: Windows 11
• Version 3.195.11

[tinker45]

also experiencing this issue with Linux Desktop Clients in versions 3.195.1, 3.195.11, and 3.195.3. I rolled back to Docker Image standardnotes/server:5c02435ee478b893747d3f9e41062aae12d7ff10 and it resolved the issue.

[kjleitz]

Also experiencing this on the latest stable release of the MacOS desktop app (3.194.13) when trying to connect to my self-hosted server. Mobile app works fine, but desktop app has this repeating login issue.

Prevented me from using my Offline Activation code since the iOS app doesn't let you enter it. Ended up having to self-host the web app, too, just to enter the code.

Currently it's also preventing me from setting up automatic backups, because the desktop application is required.

Tried downgrading the server to the image @tinker45 suggested, which did allow login. Then upgraded the server to latest again, and the auth persisted across an app restart. I don't know how long it will persist, though... maybe until next auth?

I would really rather not run the 7-month-old image full-time. It's not clear to me what has changed since then.

From the commit for the last release it looks like all the CHANGELOG.md updates only mention version bumps. 🤷‍♂️

There's also the fact that the rollback image we're discussing is from March, in between the January release and the June release (see the image tags for standardnotes/server on Dockerhub), and it's not mentioned in any of those CHANGELOG.md updates AFAICT. I'm not sure how to find out what's in that one.

The only possibly relevant thing I can see from skimming the changes in the last release is maybe this addition of COOKIE_DOMAIN and some other COOKIE_* environment variables to the auth service. Maybe the authentication cookie is scoped to a certain domain by default (or the domain of the self-hosted app) and you need to set it to the domain of your self-hosted server in order for the cookie to actually work, and this instruction was accidentally omitted from the .env.sample that you copy into your server and modify during setup? That would make some sense, considering that the Domain attribute on the Set-Cookie header (MDN) is used in this kind of way.

I'm a little concerned, though, that there haven't been any releases in the past 4 months, and that this forum seems maybe to be unmonitored...? Am I yelling into the void, here?

Edit: Some system info.

App:
OS: MacOS Sonoma (14.7)
Version 3.194.13

Server:
OS: Ubuntu Server 24.04
Server version: latest
Running via docker-compose according to the official guide.

[kjleitz]

I hate to ping maintainers directly, but given how little activity there is here... @karolsojko you alive?

[acmartinsalmeida]

SOLVED by #3635

same for me on fresh install, last versions of server (docker method)

Get an error about cookie in server logs logs/auth.log

{"application":"Desktop-3.194.13","level":"error","message":"No cookies provided for cookie-based session token."...

[zc-devs]

#3635 doesn't work for me (in COOKIE part, didn't try downgrade the server).

Desktop app standard-notes-3.195.12-win-x64
Server image standardnotes/server@sha256:e8868bf70e6aa470578f110e953f1402ff985a507e48d4e2282f3fbc47561234

Tried server URL http://sn.domain.local:3000 with 127.0.0.1 sn.domain.local in hosts and with envs

COOKIE_DOMAIN=sn.domain.local
COOKIE_SECURE=false

as well as server URL http://localhost:3000 with envs

COOKIE_DOMAIN=localhost
COOKIE_SECURE=false
COOKIE_PARTITIONED=false

Result is the same:

{"level":"debug","message":"Could not decode token with primary decoder, trying fallback decoder.","service":"auth:server"}
query: SELECT `session`.`uuid` AS `session_uuid`, `session`.`user_uuid` AS `session_user_uuid`, `session`.`private_identifier` AS `session_private_identifier`, `session`.`hashed_access_token` AS `session_hashed_access_token`, `session`.`hashed_refresh_token` AS `session_hashed_refresh_token`, `session`.`access_expiration` AS `session_access_expiration`, `session`.`refresh_expiration` AS `session_refresh_expiration`, `session`.`api_version` AS `session_api_version`, `session`.`user_agent` AS `session_user_agent`, `session`.`created_at` AS `session_created_at`, `session`.`updated_at` AS `session_updated_at`, `session`.`readonly_access` AS `session_readonly_access`, `session`.`version` AS `session_version`, `session`.`application` AS `session_application`, `session`.`snjs` AS `session_snjs` FROM `sessions` `session` WHERE `session`.`private_identifier` = ? -- PARAMETERS: ["363fa2cda3719dd60b789dcc697aaf98"]
{"application":"Desktop-3.195.12","level":"error","message":"No cookies provided for cookie-based session token.","method":"POST","secChUa":"\"Not/A)Brand\";v=\"8\", \"Chromium\";v=\"126\"","service":"auth:server","sessionUuid":"8c7d7a2a-d3a1-4be3-998b-47c948033eb2","snjs":"2.209.5","url":"/v1/items","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) StandardNotes/3.195.12 Chrome/126.0.6478.114 Electron/31.1.0 Safari/537.36","userId":"e8c7cf95-b1a9-4e9e-a740-06302828f872"}
query: SELECT `revoked_session`.`uuid` AS `revoked_session_uuid`, `revoked_session`.`private_identifier` AS `revoked_session_private_identifier`, `revoked_session`.`user_uuid` AS `revoked_session_user_uuid`, `revoked_session`.`received` AS `revoked_session_received`, `revoked_session`.`created_at` AS `revoked_session_created_at`, `revoked_session`.`received_at` AS `revoked_session_received_at`, `revoked_session`.`user_agent` AS `revoked_session_user_agent`, `revoked_session`.`api_version` AS `revoked_session_api_version` FROM `revoked_sessions` `revoked_session` WHERE `revoked_session`.`private_identifier` = ? -- PARAMETERS: ["363fa2cda3719dd60b789dcc697aaf98"]
{"level":"debug","message":"Could not decode token.","service":"auth:server"}
{"level":"debug","message":"[authenticate-user] No authentication method found for tokens: {\"authTokenFromHeaders\":\"2:363fa2cda3719dd60b789dcc697aaf98\",\"authCookies\":{},\"requestMetadata\":{\"snjs\":\"2.209.5\",\"application\":\"Desktop-3.195.12\",\"url\":\"/v1/items\",\"method\":\"POST\",\"userAgent\":\"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) StandardNotes/3.195.12 Chrome/126.0.6478.114 Electron/31.1.0 Safari/537.36\",\"secChUa\":\"\\\"Not/A)Brand\\\";v=\\\"8\\\", \\\"Chromium\\\";v=\\\"126\\\"\"}}","service":"auth:server"}

[birdmanmandbir]

SOLVED by #3635
Add COOKIE_DOMAIN=app.mydomain.com in .env app, docker-compose down && docker-compose up -d

[joehand]

The COOKIE_DOMAIN needs to cover both the server and web app.

I had the web app at notes.site.com and server at notes-api.site.com. Setting COOKIE_DOMAIN to notes.site.com was insufficient, but site.com worked.

I moved the api to api.notes.site.com with COOKIE_DOMAIN=notes.site.com which now works.

[piit79]

The COOKIE_DOMAIN needs to cover both the server and web app.

I don't think that's the case, @joehand. The COOKIE_DOMAIN variable is used to set the cookies from the API, so it needs to be set to the API server hostname. That's how I have it set up and it's working without any issues.