Default cache timeout

[morrah]

Default cache TTL is 300s, but default django session is 2 weeks; user could want to have a page opened for almost 2 weeks but 5 minutes later he gets 404 responses only.
Does it make sense to set default timeout for select2 cache to a first explicitly declared timeout or to a default session age otherwise?
Kinda

if settings.SELECT2_CACHE_BACKEND:
    timeouts = [
        settings.get('CACHES', {}).get(settings.SELECT2_CACHE_BACKEND, {}).get('TIMEOUT'),
        settings.SESSION_COOKIE_AGE,
        60*60*24*7*2, # default 2 weeks https://docs.djangoproject.com/en/3.1/ref/settings/#session-cookie-age 
    ]
    default_timeout = list(filter(None, timeouts)).pop(0)

Also another question somehow linked to caching.
Curious about reasons behind using uuid for every widget instance instead of predictable hashing for a db field - 'database name + table name + column name' as a hash input for example.
Thus we don't need to use cache as an external consistent storage for uuids, because every django process can calculate this same field_id on its own.
Though it requires to whitelist somewhere (in settings?) select2-accessible db fields. What are the other downsides?

[codingjoe]

Hi @morrah,

Thanks for reaching out. As I understand it, you are asking first about the cache timeout and second about ids. I'll try to answer them one by one:

Cache timeout

The answer to that is relatively simple. It is recommended your cache backend. I would advise you to set the appropriate timeout for that backend depending on your application.

HASH vs UUID

It's not as simple as you make it out to be. No only could you have two querysets on the same table, but you could build forms and widgets dynamically. All of which I and many other users have done in the past. This ruins the deterministic approach. However, that is something we do in Django's admin. However, this package provides functionality that goes beyond that. Having a UUID as an identifier to retrieve the correct query information works for all cases.

I hope that answers you questions.

Best,
Joe

[CleitonDeLima]

To be honest, i don't understand how does it ruin. Having a hash for a database field instead of a widget instance hash/uuid makes possible to re-calculate this hash anytime and it would be still the same for any dynamically created widget until database schema is changed.

You can have more than one field with the same model but a different queryset, the hash you placed would not work. I had problems when another approach was used. UUID was the best solution.

[morrah]

Now i see.

A database field isn't enough, widget arguments are also needed - like case-sensitivity for fields, max results, etc - which are used to build a specific queryset.
And we don't want to let a client to control those arguments, so we have to keep them (or an already built and serialized queryset) on a server side.

What if we serialize and render a queryset in an encrypted form to a client?
It's not too heavy for a client, but allows us to avoid whole queryset caching thing.

Just curious about alternatives to keeping every instance of every requested queryset for two weeks in my cache :D

[codingjoe]

HI @morrah,

funny that you mention it, I was actually considering this approach. However, it seemed too much of a potential security risk without delivering a huge benefit. In your example, you would execute SQL directly from a users input. Yes, it needs to be decrypted, but if a developer builds another view somewhere that uses the secret key to encrypt any user input, you would have a fully functioning SQL-Injection vector.

Regarding the 5-minute timeout recommendation, where did you find that. I am having trouble to find a place where we recommend this exact timeout interval. If so, I'd be happy to fix that.

Best,
Joe

[morrah]

too much of a potential security risk

Well, yea, you're right. Maybe it's possible to serialize+encrypt only those widget arguments that is enough to re-construct queryset with an appropriate argument validation? I've seen a similar practice in .net, there's an encryption of a session cookie by default, i suppose to keep bits of sensitive data there.

the 5-minute timeout recommendation, where did you find that

Sorry, my bad, 300s isn't recommendation of yours, but a common default for any django cache. And i suggested to override this value to django session cookie age for select2 cache, unless developer specified otherwise. Because [in my humble opinion] it's the most common case: you want your widgets to live as long as user could have his session.

[codingjoe]

too much of a potential security risk

Well, yea, you're right. Maybe it's possible to serialize+encrypt only those widget arguments that is enough to re-construct queryset with an appropriate argument validation? I've seen a similar practice in .net, there's an encryption of a session cookie by default, i suppose to keep bits of sensitive data there.

Again, that wouldn't change security implications. An attacker can easily create a malicious cookie.
Besides, we only store the bare minimum data needed to reconstruct the state.

the 5-minute timeout recommendation, where did you find that

Sorry, my bad, 300s isn't recommendation of yours, but a common default for any django cache. And i suggested to override this value to django session cookie age for select2 cache, unless developer specified otherwise. Because [in my humble opinion] it's the most common case: you want your widgets to live as long as user could have his session.

I don't believe there is a one size fits all timeout. On most of my applications your configuration would overflow my cache storage.