Opened 7 years ago

Closed 22 months ago

#12907 closed Bug (needsinfo)

Problems with django admin on Jython with custom user models

Reported by: gbauer Owned by: nobody
Component: Database layer (models, ORM) Version: 1.1
Severity: Normal Keywords: jython
Cc: Leo Soto M. Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

It looks like django passes the unparsed string parameter from the URL to the sql method that fetches the custom user instance from the database when you edit a custom user in the django admin. The result on Jython is that due to the different backend, the database complains that it can't compare integers and varchars.

/home/gb/Projects/JythonPlay/Lib/site-packages/doj/backends/zxjdbc/common.py in execute

self.cursor.execute(sql, params) ...

Local vars

params (u'4',)
self <doj.backends.zxjdbc.postgresql.base.CursorWrapper object at 0x4af>

sql
'SELECT "auth_group"."id", "auth_group"."name", "Organisation_rolle"."group_ptr_id", "Organisation_rolle"."kurz_name" FROM "Organisation_rolle" INNER JOIN "auth_group" ON ("Organisation_rolle"."group_ptr_id" = "auth_group"."id") WHERE "Organisation_rolle"."group_ptr_id" = ? '

I am currently not sure wether this is a problem of the backend or the admin, but for some reason I think the admin could be to be blamed - an sql command shouldn't get wrong types for parameters. Allthough it could be a result of the %s vs ? handling of parameters - the JDBC backend seems to use prepared parameterized statements, not string substitutions with pre-escaped values.

Change History (10)

comment:1 Changed 7 years ago by Leo Soto M.

Cc: Leo Soto M. added
Keywords: jython added
Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

comment:2 Changed 7 years ago by Russell Keith-Magee

Resolution: invalid
Status: newclosed

I'm going to close this invalid - given that none of the official DB backends have this problem, I suspect this is a problem with the JDBC backend. If you can provide specific evidence that Django is using the PEP 249 DB-API incorrectly, please reopen.

comment:3 Changed 7 years ago by gbauer

Resolution: invalid
Status: closedreopened

Sorry, but I think at is at least in parts a problem of Django admin, in that there explicitely is a parameter passed from the URL down to the SQL level as unprocessed string which triggers the problem. Just closing it as invalid won't cut it, at least a change in documentation that all parameters in backends have to be accepted as either their native format or strings needs to be done - even better would be some reasoning why the admin passes on a key value for an object not as the expected integer but some string.

Or rephrased: I think it should be legal for backends to assume that parameters can be passed into preprocessed statements as parameters without getting invalid data types.

So regardless of what the specific backend in question does or does not do wrong - shouldn't the value for the User id be an integer at that moment and not a string? That it's a string at that point isn't a problem of the backend for sure ...

I think this values some level of discussion - especially under the aspect of possible sql vulnerabilities if values are passed down as strings without being converted into their required target types. I am not saying there actually is a security vulnerability, but at least it's something that smells of possible problems ahead.

comment:4 Changed 7 years ago by Russell Keith-Magee

Component: django.contrib.adminDatabase layer (models, ORM)
Triage Stage: UnreviewedAccepted

Ok - looking deeper, this is an issue with model inheritance.

Based on your sample SQL, I'm guessing that you've subclassed Group (not User like your instructions say), and it's this Group subclass that you're trying to edit. In this specific case, the SQL that is generated seems to use a string rather than an integer.

If you try to view the auth.Group base class, the query rolls out as follows:

SQL: SELECT "auth_group"."id", "auth_group"."name" FROM "auth_group" WHERE "auth_group"."id" = %s  
PARAMS: (1,)

That is - when inheritance isn't involved, the query parameters roll out fine. It's only when you add inheritance to the mix that the problem emerges. This might be due to the admin URL handling not processing the primary key value properly, or it might be due to the query handling for the inheritance join. Either way, it doesn't appear to be a JDBC problem.

comment:5 Changed 5 years ago by Luke Plant

Type: Bug

comment:6 Changed 5 years ago by Luke Plant

Severity: Normal

comment:7 Changed 5 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:8 Changed 5 years ago by Aymeric Augustin

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:9 Changed 4 years ago by Aymeric Augustin

Status: reopenednew

comment:10 Changed 22 months ago by Tim Graham

Resolution: needsinfo
Status: newclosed

Reading this ticket, I don't get a clear idea of the problem or how we can reproduce it. Please reopen if you can add more details and confirm that the issue still exists 5 years later, thanks.

Note: See TracTickets for help on using tickets.
Back to Top