Having enabled="true" in json data when creating user will produce 500

[Chmouel Boudjnah]

when we have enabled="true" (with double quotes) in the json blob keystone will 500.

REQ:

 '{
    "user": {
        "email": "'XXXX",
        "enabled": true,
        "id": "XXXXXX",
        "name": "'XXXXXX,
        "password": "XXXXX",
        "project_id": "TENANT_ID",
        "username": "'XXXXX"
    }
}

user_data:{'username': <email address hidden>', 'project_id': u'TENANTID-XXXXX2638624862', 'name': <email address hidden>', 'password': u'XXXXX-PASS', 'enabled': u'true', 'email': <email address hidden>', 'id': '9cf336dc3684400686454e093ac42f12'}
(root): 2013-01-30 13:50:32,681 ERROR wsgi __call__ invalid literal for int() with base 10: 'true' (original cause: ValueError: invalid literal for int() with base 10: 'true') 'INSERT INTO user (id, name, password, enabled, extra) VALUES (%s, %s, %s, %s, %s)' [{'extra': {'username': <email address hidden>', 'project_id': u'TENANTID-XXXXX2638624862', 'email': <email address hidden>'}, 'password': '$6$rounds=40000$2J7ChjfjKYLyo/sI$41VexgJAA9aHvbNlPwDFM6/qQb59vovGLS0MdTGGI00nWHkWKy6j0eTgRuVgjCEVQChQY04G2LbnWU/ynK.4w.', 'enabled': u'true', 'id': '9cf336dc3684400686454e093ac42f12', 'name': <email address hidden>'}]

[gordon chung (chungg)]

the code currently anticipates a boolean value rather than a string.

is the bug raised because you expect boolean string values to be handled as well?

[Dolph Mathews (dolph)]

String values should NOT be handled, but an appropriate 400 error should be raised ("message": "Expected boolean value in enabled attribute.")

[bsemp (bruno-semperlotti)]

https://review.openstack.org/#/c/27176/4

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/27176
Committed: http://github.com/openstack/keystone/commit/840a0758e7dc12360acf83106526436135e8f814
Submitter: Jenkins
Branch: master

commit 840a0758e7dc12360acf83106526436135e8f814
Author: Bruno Semperlotti <email address hidden>
Date: Fri Apr 19 16:22:58 2013 +0200

    Http 400 when user enabled is not a boolean

    When creating or updating a user, no type check was performed on the
    enabled attribute. Therefore, if enabled value in JSON/XML is not a
    boolean buta string or an int, keystone responds with an incorrect
    Http 500 error code and the stacktrace.

    The change introduces a type validation of the enabled attribute
    at backend and api layer. If the type is not a boolean, keystone
    now returns an appropriate Http 400 error code with a message
    pointing a bad format for the attribute.

    Test cases have been added to file test_backend and
    test_content_types for testing the case when enabled attribute is a
    string or int when creating or updating user.

    The same correction can be done for create/update projects, domains.

    Change-Id: I7d2fe3acf0c4dbd3ce5bdf9f4d059df085853b84
    Fixes: bug #1110435