Fix SESSION_COOKIE_NAME and secret_key being random values

[alanvitor]

This fixes the problem with SESSION_COOKIE_NAME and secret_key being random values. The secret_key is now static, which is necessary for encrypting user data and session.

The minor fix in installing_deps.sh is for running a docker container as root. sudo in this case won't work, so we're checking current user and installing sudo if needed.

[adulau]

Thanks for the pull-request.

We do a reset if the private-key at each restart of the service allowing to kill and clean active sessions. What's your use-case to require a fixed private-key? Security wise it sounds like a bit more risky.

[alanvitor]

My use case:
a load balancer and 2 or more EC2 instances. Each one generated a different key, and a simple refresh on the interface was logging out the user. The same thing happens when I try to run the application in containers.

In my case, instead of generating the key in code, I generate the key in a shared location. So each instance gets the same key.

And now it would be an environment variable, so there is no problem generating a private key on each restart.

[adulau]

I see. Why don't use sticky session on the reverse proxies/load balancers? but how do you load-balancing between the kvrocks database? I won't work as is with the current design of AIL.

[alanvitor]

Let me add more context to understand what got me to this point.

I want to scale it up by separating some services into exclusive instances (and it's challenging me). For example, I want to have 2 instances for the application, 1 for ARDB, and 1 for Redis and KVRocks. LAUNCH.sh is helping me to run these services separately.

In this process, I found some quick wins, and session handling was one of them. Sticky sessions are a good approach, but I think they will add another layer of complexity that we can solve in the application.

@adulau, thanks for pointing out those items that I forgot to mention.

[SteveClement]

Can we close this @Terrtia it's 2025 after all ;)