Add namespace value to TokenRedis source

[so-saf]

I suggest adding a new 'namespace' parameter to the TokenRedis plugin. This is useful when multiple clients use the same Redis instance.

Another parameter has been added to src and now the source format is as follows:
host[:port[:db[:password[:namespace]]]]
All changes are covered by tests, and the old ones are updated.

[CendioOssman]

This looks like a convention, rather than something fundamental to redis? That makes me cautious about adding it, as not everyone might follow that convention.

Why can't users include this prefix in the token themselves?

[so-saf]

@CendioOssman Thank you for such a quick response!

This looks like a convention, rather than something fundamental to redis?

Yes, you are right, this is not a built-in redis feature. But, as far as my experience suggests, this is a fairly common practice.

Why can't users include this prefix in the token themselves?

Because namespace is some kind of abstraction for redis, and users do not need to know about the internal structure of keys.

Perhaps the example will make it clearer what I mean.

I have a small application that provides noVNC with access to machines. One way or another, the user receives a token that uniquely identifies a specific virtual machine. By specifying this token, the user can connect:

wss://host/websockify?token=3c25422f-1921-4954-ac72-3f3d0368b99d

Tokens are stored in redis, which is used by several other services, and if we want to separate the keys of one application from another, then we need to add a prefix to the key. In this case, the connection will look like this:

wss://host/websockify?token=myappname-websockify-prod-1:3c25422f-1921-4954-ac72-3f3d0368b99d

The presence of a prefix directly in the key seems at least strange, and at most unsafe. Therefore, in my application I use a plugin that adds this functionality.

This PR was created because it is useful and does not break backward compatibility.

Regardless of whether this PR is accepted or not, I want to say that the noVNC project is really very cool. Thank you :)

[CendioOssman]

Ah, yes. The security aspect is a good point. You need to be able to keep that out of end user control.

I quickly googled redis and namespaces, and it does seem to be a strong convention, encouraged by the redis people themselves:

https://redis.io/blog/5-key-takeaways-for-developing-with-redis/
https://github.com/resque/redis-namespace
https://norman-lm-fung.medium.com/redis-namespace-2913a9708301

So I think it's reasonable for us to follow that convention as well.

The links above point out one concerning thing, though. The namespace can be multiple levels deep. And they also use : as the separator. So how would we solve if someone needs a nested namespace with websockify?

[so-saf]

@CendioOssman I really didn't think about nested namespaces!

I see three possible solutions:

1. If the namespace contains nested names, then you need to separate it with quotation marks: localhost:::"first:second"
2. Escape the colon character: localhost:::first\:second
3. Since the first two solutions don't seem natural, I would suggest not supporting nested namespaces at all.

Which solution do you consider preferable?

[CendioOssman]

I'm afraid I'm not familiar with redis, so I don't know how much of a limitation not supporting it would be.

We could skip it for now, as long as we have an opening for adding it in the future. And I don't see anything in your code that would prevent is from doing 1. or 2. in the future.

[so-saf]

I would like to implement the first option. I will come back to you with a solution :)

[so-saf]

Thanks for waiting!
I wrote a new function parse_source_args in the token_plugins module and use it in TokenRedis.__init__ instead of src.split(":").
In addition, I wrote tests for the new function.

[CendioOssman]

Looks good! Thanks for your hard work!