Changes between Initial Version and Version 1 of Ticket #34370, comment 2


Ignore:
Timestamp:
Feb 24, 2023, 1:34:37 PM (21 months ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #34370, comment 2

    initial v1  
    33This issue is really just #27397 on save instead of reads because `sqlite3` raises an `OverflowError` on when dealing with [https://github.com/python/cpython/blob/090819ec5faea2d0c2cdf6bcfdbbc9df144a8aad/Modules/_sqlite/util.c#L143-L167 longs that overflow 64 bits].
    44
    5 In order to properly address #27397 by raising `(Empty|Full)ResultSet` when provided overflowing values we need `integer_field_range` to be defined anyway. Once it's the case we could adapt lookups such as `Exact`, `GreaterThan(Eq)?` to special case literal right-hand-sides that overflow their left hand side ranges to raise `EmptyResultSet` and the `LowerThen(Eq)?` to raise `FullResultSet` and not only address #27397 for SQLite but also deal protect against [https://code.jeremyevans.net/2022-11-01-forcing-sequential-scans-on-postgresql.html a form of DDoS vector on PostgreSQL] that is trivial to exploit (think of any view that accepts `\d+` or `<int:pk>` to perform a `Model.objects.get(pk=pk)`).
     5In order to properly address #27397 by raising `(Empty|Full)ResultSet` when provided overflowing values we need `integer_field_range` to be defined anyway. Once it's the case we could adapt lookups such as `Exact`, `GreaterThan(Eq)?` to special case literal right-hand-sides that overflow their left hand side ranges to raise `EmptyResultSet` and the `LowerThen(Eq)?` to raise `FullResultSet` and not only address #27397 for SQLite but deal protect against [https://code.jeremyevans.net/2022-11-01-forcing-sequential-scans-on-postgresql.html a form of DDoS vector on PostgreSQL] that is trivial to exploit (think of any view that accepts `\d+` or `<int:pk>` to perform a `Model.objects.get(pk=pk)`).
Back to Top