Creating a "key" type order without a name set in "meta" produces a null when retrieved

Bug #1376469 reported by John Vrbanac on 2014-10-01
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
Juan Antonio Osorio Robles

Bug Description

Creating a "key" type order without a name set in "meta" produces a null when retrieved. Previously we populated
this value with the UUID of the secret. The expected behavior can be seen by creating a secret without a name attribute.

Steps to Reproduce:

Create the order without a name attribute in meta:

curl -X POST -H "X-Auth-Token:$AUTH_TOKEN" -H "Content-Type:application/json" -H "X-Project-Id:$PROJECT_ID" -d '{
  "type": "key",
  "meta": {
    "mode": "cbc",
    "bit_length": 256,
    "algorithm": "aes",
    "payload_content_type": "application/octet-stream"
}' http://localhost:9311/v1/orders

Retrieve and inspect the resulting order:

curl -X GET -H "X-Auth-Token:$AUTH_TOKEN" -H "X-Project-Id:$PROJECT_TOKEN" http://localhost:9311/v1/orders/ed42542a-c8b4-405f-acb2-5fbddc9a2823

    "created": "2014-10-01T21:31:40.963033",
    "meta": {
        "algorithm": "aes",
        "bit_length": 256,
        "expiration": null,
        "mode": "cbc",
        "name": null,
        "payload_content_type": "application/octet-stream"
    "order_ref": "http://localhost:9311/v1/orders/ed42542a-c8b4-405f-acb2-5fbddc9a2823",
    "secret_ref": "http://localhost:9311/v1/secrets/2ccd16d6-54d3-4cfa-94b3-ea2d7386aa0a",
    "status": "ACTIVE",
    "type": "key",
    "updated": "2014-10-01T21:31:41.315161"

Changed in barbican:
status: New → Confirmed
importance: Undecided → Low
milestone: none → kilo-1
Changed in barbican:
milestone: kilo-1 → none
tags: added: verified

Well, is adding the uuid as the name of the secret even the correct behavior? It seems that in the database, at least for secrets, the name is stored as empty, and only when the secret it's fetched then the id is set to the 'name' attribute: when there is a secret_model.to_dict_fields() . This is actually called when fetching secrets: in the augment_fields_with_content_types function. Anyway, the point is that actually the secrets do not have the name replaced by the id in the database, which means that if we try to fetch the list of secrets, and filter by using the id, it will not work.

So, if the desired behavior is to have the secrets always with some sort of name, then we could start storing the uuid when the name is empty in the database; And the same would be done for orders. If this is not what we want, then I would say we should stop returning the uuid in the 'name' field for secrets and let the behavior that the orders have be the "desired" one. Any thoughts?

Changed in barbican:
assignee: nobody → Juan Antonio Osorio Robles (juan-osorio-robles)
John Wood (john-wood-w) wrote :

Yeah, this 'UUID for no name' behavior goes back to the early days of the project, and seems to violate principle of least surprise a bit, esp. since it is non-querable. I don't believe this behavior was ever documented as part of the API contract as well. Therefore I'd support removing this behavior altogether and keeping the secret name field optional.

OK, I'll go ahead and do that.

Changed in barbican:
status: Confirmed → Invalid
assignee: Juan Antonio Osorio Robles (juan-osorio-robles) → nobody

Hopefully there will be a bit more discussion on this and then we decide what to do.

Changed in barbican:
assignee: nobody → Juan Antonio Osorio Robles (juan-osorio-robles)
status: Invalid → Opinion

uhm... I didn't know that the "Opinion" bugs didn't show up in the list. I'll set it as incomplete meanwhile.

Changed in barbican:
status: Opinion → Incomplete

Alright, so we have agreed that we will actually return null values if a value was not given by the user. I'll upload a patch for this soon.

Changed in barbican:
status: Incomplete → Invalid

Submitter: Jenkins
Branch: master

commit c098455d2ea7205ad24744fe4bedd6d2c673934a
Author: Juan Antonio Osorio Robles <email address hidden>
Date: Mon Nov 2 10:26:54 2015 +0200

    Allow null values for secret names

    This secret allows null values for names in secrets as discussed a
    couple of cycles back.

    Since the code for the mocked client in the functional tests actually
    filters out null values, it is currently not possible to write a
    functional test for this in this functional test code base. However, it
    will be written as part of the python-barbicanclient functional test

    Change-Id: I68330d1d1b13e1bbb6436ca4f6684a76af3babd3
    Related-bug: #1425667
    Related-bug: #1376469

Changed in barbican:
milestone: none → mitaka-1
status: Invalid → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers