able to POST and GET custom attribute/field in JSON

[Sathianantha Thilagar]

Problem:

As part of the JSON body while creating user, the custom attribute/field I added was used by keystone without causing any error/warning.

% curl -ik -X POST -H "X-AUTH-TOKEN: $token" -H "Content-Type: application/json" https://keystone:35357/v3/users -d '{"user": {"test_custom_field":"my value","name": "newuser"}}'
 HTTP/1.1 201 Created

The same custom attribute/field is accessible through curl GET while openstack-client filters this attribute/filed while printing.

The setup version used here is Juno release.

Expected behavior:

HTTP 400

[Dolph Mathews (dolph)]

This is entirely by design, but everyone in keystone-core would love to see that feature be removed.

[Deepti Ramakrishna (dramakri)]

> This is entirely by design
What was the original rationale behind this design?

> ... everyone in keystone-core would love to see that feature be removed.
Which feature? The ability to specify custom properties (& values) while creating users? If so, what about existing users already created with custom properties?

To maintain backward compatibility, should we continue to allow reading custom properties while removing the ability to *write* them?

If we can make a GET request to retrieve custom properties, it means that they are stored in the database. Will fixing this bug require changing the database schema?

Does this also need an APIImpact tag?

[Steve Martinelli (stevemar)]

unassigning due to inactivity.

i'm also not sure if we can fix this, as deepti says, we need to continue to support this for backward compatibility.

on a somewhat related note, we now have schema validation for v3 operations; https://github.com/openstack/keystone/blob/9.0.0.0b1/keystone/identity/schema.py

[Morgan Fainberg (mdrnstm)]

lots of discussion, this is something we've long since determined is mostly unfixable FOR compat reasons.