Opened 7 years ago

Closed 21 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: leosoto Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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/ in execute

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

Local vars

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

'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 leosoto

  • Cc leosoto added
  • Keywords jython added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 7 years ago by russellm

  • Resolution set to invalid
  • Status changed from new to closed

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 deleted
  • Status changed from closed to reopened

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 russellm

  • Component changed from django.contrib.admin to Database layer (models, ORM)
  • Triage Stage changed from Unreviewed to Accepted

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 lukeplant

  • Type set to Bug

comment:6 Changed 5 years ago by lukeplant

  • Severity set to Normal

comment:7 Changed 5 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:8 Changed 5 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:9 Changed 3 years ago by aaugustin

  • Status changed from reopened to new

comment:10 Changed 21 months ago by timgraham

  • Resolution set to needsinfo
  • Status changed from new to closed

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