Problems with django admin on Jython with custom user models

[gbauer]

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.

[Russell Keith-Magee]

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.

[gbauer]

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.

[Russell Keith-Magee]

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.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Tim Graham]

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.