You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
django.db.utils.InternalError: current transaction is aborted, commands ignored until end of transaction block
This only happens when the token client is used, supplying the malformed IPv4 through curl or mreg-cli is gracefully rejected with a proper error message and return code 400 from REST.
This also only happens if IPv4 is malformed like shown above, with improper number of fields. Invalid IPv4 addresses with right number of fields, like 10.0.0.400 are gracefully handled.
The text was updated successfully, but these errors were encountered:
The same thing is actually true for IPv6. Addresses like 2001:db8:::1 result in the same crash, while the likes of 2001:db8::zzzz are handled as expected.
dmykarp
changed the title
Token client leads to crash in the db component when IPv4 for PtrOverride is malformed
Token client leads to crash in the db component when IP address for PtrOverride is malformed in number of fields
Apr 5, 2019
Should probably try to create a minimum-instance of code and se if it can be reproduced. Tokens should not matter, so a tiny drf project with a Host and PtrOverride model, and a view for PtrOverride.
The problem is related to the model PtrOverride's unique=True-constraint. As the test does a SELECT (1) AS "a" FROM "ptr_override" WHERE "ptr_override"."ipaddress" = '10.0.0.4.44'::inet LIMIT 1 to check contrains before running the data through the validator it fails.
The code like this:
leads to a crash in the database component.
This only happens when the token client is used, supplying the malformed IPv4 through curl or mreg-cli is gracefully rejected with a proper error message and return code 400 from REST.
This also only happens if IPv4 is malformed like shown above, with improper number of fields. Invalid IPv4 addresses with right number of fields, like
10.0.0.400
are gracefully handled.The text was updated successfully, but these errors were encountered: