Re: Swappable sessions

2020-04-14 Thread Lorenzo Peña
Thanks Adam, looks like the link you posted covers it all. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-develope

Re: Hashing Session Keys in backends

2020-04-14 Thread Adam Johnson
Hi Mark Thanks for looking into this tricky security issue. I'm suggesting to use the names frontend_key and backend_key for these two > concepts. > They seem reasonable to me, as long as there's an explanatory comment. Perhaps it even needs documenting for third party backends. My second sugge

Re: Swappable sessions

2020-04-14 Thread Adam Johnson
Hi Lorenzo Using a different Session model is already supported - see the docs: https://docs.djangoproject.com/en/3.0/topics/http/sessions/#extending-database-backed-session-engines . Or is there something beyond that which you wanted? Thanks, Adam P.S. Please don't start your message addressed

Swappable sessions

2020-04-14 Thread Lorenzo Peña
Hello fellows! Has there ever been any discussion about making the Session model from django.contrib.sessions a swappable model? Sometimes it's required to enhance the session model in order to track more information. There are alternatives like django-user-sessions, but replacing the contrib s

Re: Proposal to not implicitly create varchar/text-pattern opclass indexes on PostgreSQL

2020-04-14 Thread Hannes Ljungberg
The `*_pattern_ops` operators all support ordinary equality comparisons but not <, <=, >, or >= comparisons. So a regular `WHERE col = 1` would be able to use a `_like` index. See: https://www.postgresql.org/docs/current/indexes-opclass.html But it's still interesting that the query planner al

Re: Proposal to not implicitly create varchar/text-pattern opclass indexes on PostgreSQL

2020-04-14 Thread Adam Johnson
Yes that one is odd. Looking more closely, django-oauth-toolkit doesn't make any LIKE queries, and doesn't seem to ever have done so. It seems rather that PostgreSQL is using the index to fulfill the unique constraint, as the corresponding '_uniq' index is not being touched: core=> select indexrel

Re: Proposal to not implicitly create varchar/text-pattern opclass indexes on PostgreSQL

2020-04-14 Thread charettes
Makes we wonder under which circumstances an OAuth token would need to be looked up using LIKE. I would expect the unique b-tree index which covers exact lookups to be sufficient. Simon Le mardi 14 avril 2020 09:01:48 UTC-4, Adam Johnson a écrit : > > For some numbers: I just checked on a long-

Re: Proposal to not implicitly create varchar/text-pattern opclass indexes on PostgreSQL

2020-04-14 Thread Adam Johnson
For some numbers: I just checked on a long-running client project using PostgreSQL, and it looks like several of the *_like indexes are in use: core=> select right(indexrelname, 10), idx_tup_read, idx_tup_fetch from pg_stat_all_indexes where indexrelname like '%_like' order by 1; right| id

Re: Proposal to not implicitly create varchar/text-pattern opclass indexes on PostgreSQL

2020-04-14 Thread Hannes Ljungberg
Thanks for your reply Tim, I also fail to see a "clean" upgrade path. The way I’ve been thinking of, is to just as you wrote, keep the code for deletion of the index so people who migrate to the Index-class will get it removed properly. Since it uses `IF EXISTS` it should be future-proof. We co

Technical Board statement on type hints for Django

2020-04-14 Thread Carlton Gibson
Hi all. The question of using typing, or type hints, or type checking, in (or with) Django has come up several times. Whether we would add inline annotations, or use stub files, or what? Most recently, this resulted in a draft DEP[0] to try and formalize the situation, followed by a PR[1] ad