Set-Cookie: SessionId not properly sent?

Hello Community,

I am working in a project, which uses CVAT and CVAT uses Django as the authentication framework in the background. Before going into detail, which versions and configurations I am using, I want to start with the error I am facing and the error, which I think causes this.

So basically I cannot login to the django admin console and remain at the login screen. So the first error which is described in the Admin FAQ i-can-t-log-in-when-i-enter-a-valid-username-and-password-it-just-brings-up-the-login-page-again-with-no-error-messages (sorry, I am only allowed to post 2 links in this question). Of course, I have tried the proposed solution.

What I currently suspect, is a wrong sessionid cookie, which is not sent back by my browser (Firefox):
When logging in, the POST request answers with the following cookie (sessionid, domain and csrf token are changed):

Set-Cookie csrftoken=SomeToken; expires=Tue, 07 Nov 2023 14:55:45 GMT; Max-Age=31449600; Path=/; SameSite=Lax, sessionid=SomeSessionId; Domain=myfunction.azurewebsites.net; expires=Tue, 22 Nov 2022 14:55:45 GMT; HttpOnly; Max-Age=1209600; Path=/; SameSite=Lax

In the next GET request to myfunction.azurewebsites[dot]net/admin, Firefox does send the CSRF Token, but not the sessionId. Therefore I suspect something is wrong with the cookie.

My setup is the following:

  • CVAT 2.2.0 (GitHub - opencv/cvat at v2.2.0) provides a docker-compose file, that I have started on a virtual machine in Azure. On the VM all traffic is routed through a Traefik container. *
  • Django is running in Version 3.2.15* in another container named cvat_server (middleware and config see below).
  • When I give the VM a public IP Address and access the django admin login, I dont have a problem at all. I.e. login via 1.2.3.4:8080/admin/login/?next=/admin/ works properly. I get 2 separate cookies. One contains the csrf token, another one the session id
  • To not have a public IP address for access, we are using an Azure Function as a Proxy. This means I access the admin login via myazurefunction.azurewebsites[dot]net/admin/login/?next=/admin/ . When I try to login here, I get the error described as above and Django sends 1 Cookie with csrf token AND sessionId.

What I have tried:

  • When setting SESSION_COOKIE_DOMAIN = ‘myazurefunction.azurewebsites[dot]net’, I can no longer login via the public IP address. The above cookie is the result with this setting.
  • It does not matter if I access the azure function proxy via http or https. Both do not work.
  • Several changes of SESSION_COOKIE_SAMESITE, CORS_ALLOW_ALL_ORIGINS were not successful
  • Setting CSRF_USE_SESSIONS = True, solved this problem (Set-Cookie now only contained sessionId, but not csrf token), but raised another one when using CVAT with another tool that tries to login via private network connection.

Used middlewares:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    # 'corsheaders.middleware.CorsPostCsrfMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'dj_pagination.middleware.PaginationMiddleware',
    'cvat.apps.iam.views.ContextMiddleware',
]

I think all other settings are more or less default (i.e. I dont really know, but every time I checked, if CVAT uses this setting, it was not present in the settings file). Pls forgive me for not listing all, but the settings can be found here cvat/base.py at v2.2.0 · opencv/cvat · GitHub
and in the same folder in production.py.

Any help is appreciated and kind regards,

Jörg

I don’t have any specific answers for this particular problem, but if I had to diagnose this type of problem, I’d start with:

I’d be looking closely at the http requests through this. I’d be using tcpdump (wireshark, Microsoft Message Analyzer, etc) to examine the requests passing through this component.

From the symptoms you describe here, my gut reaction is that you’re getting a session id for the proxy and not the session id being returned by Django. (I do not know this for a fact, it’s a hunch.) You would be able to verify this by looking at the request and responses on both sides of the proxy.

Hi,

thanks for your quick response. After diving further into the logs of Traefik and the Function Proxy, I figured it seems to actually be a Function Proxy error, which is described here:

So your gut reaction was the one point I needed :).

Thank you!