Server uses wrong Redis DB in some cases

[mherrmann]

The field omaha.utils.redis holds a Redis connection. It is used for the following things:

• Tracking known users of an app in the Redis key known_users:<appid>.
• Mapping user UUIDs to integer ids via a Redis mapping uid:<uuid> -> <integer id> for each user.
• Tracking a counter for generating the next such integer id, named uid:last_id.

From the definition of this field and the relevant settings, one would think that it stores the above information in the Redis database given by the setting REDIS_STAT_DB. By default, this is database 15 on the respective Redis host.

In practice, I have found that the above information is saved in database 0 instead of 15 when a REDIS_PASSWORD is supplied. The reason for this is that setting REDIS_PASSWORD changes the value of REDIS_AUTH from the empty string '' to redis://:PW@. This in turn changes the connection URL from IP:6379:15 to redis://:PW@IP:6379:15. When Django passes this to django_redis.pool.ConnectionFactory#connect(...), the former case correctly selects database 15. The latter on the other hand doesn't and uses the default value 0.

The reason for the above problem is that the redis://... URL has an incorrect format: It should be ...:6379/15 (slash 15) not ...:6379:15. Another setting does this correctly.

This problem likely also affects the REDIS_DB setting. By default, it seems to be intended to have value 1. But when a REDIS_PASSWORD is set, I am almost certain that it will have no effect, whatever the value. In other words, users of omaha-server who set REDIS_PASSWORD and REDIS_DB will be surprised by the latter having no effect.

Interestingly, this problem does not affect values set via the bitmapist library (which seems to be the main motivation for having a separate REDIS_STAT_DB in the first place). The reason for this is that the library is initialized not via a connection string, but via cleanly separated parameters.

I don't yet know how to fix this, given that there will be users of omaha-server that now already have their data in the "wrong" database. I'll likely write more in the coming days.