| 2015-02-06 22:10:46 |
Douglas Mendizábal |
bug |
|
|
added bug |
| 2015-02-06 22:11:12 |
Douglas Mendizábal |
description |
When using python-barbicanclient to store a binary blob, if the user pre-encodes the binary in base64, the client will unexpectedly drop the encoding when retrieving the secret. See code sample below:
my_payload = base64.b64encode(os.urandom(16)) # orignal base64 encoded payload
my_secret = client.secrets.create()
my_secret.payload = my_payload
my_secret.payload_content_type = 'application/octet-stream'
my_secret.payload_content_encoding = 'base64'
my_ref = my_secret.store()
retrieved_secret = client.secrets.get(my_ref)
assert retrieved_secret.payload == my_payload
The assertion fails because the retrieved secret payload is the actual bytes, not the base64 encoded payload we originally give to the client. My expectation is that the thing I give the client should be the same thing I get back, but because of the payload_content_encoding semantics, this is not the case.
A proposed solution would be to deprecate the payload_content_encoding parameter, which will prevent these odd scenarios from happening. This will probably have to be revisited once the content-type blueprint implementation lands. |
When using python-barbicanclient to store a binary blob, if the user pre-encodes the binary in base64, the client will unexpectedly drop the encoding when retrieving the secret. See code sample below:
my_payload = base64.b64encode(os.urandom(16)) # orignal base64 payload
my_secret = client.secrets.create()
my_secret.payload = my_payload
my_secret.payload_content_type = 'application/octet-stream'
my_secret.payload_content_encoding = 'base64'
my_ref = my_secret.store()
retrieved_secret = client.secrets.get(my_ref)
assert retrieved_secret.payload == my_payload
The assertion fails because the retrieved secret payload is the actual bytes, not the base64 encoded payload we originally give to the client. My expectation is that the thing I give the client should be the same thing I get back, but because of the payload_content_encoding semantics, this is not the case.
A proposed solution would be to deprecate the payload_content_encoding parameter, which will prevent these odd scenarios from happening. This will probably have to be revisited once the content-type blueprint implementation lands. |
|
| 2015-02-06 22:12:07 |
Douglas Mendizábal |
description |
When using python-barbicanclient to store a binary blob, if the user pre-encodes the binary in base64, the client will unexpectedly drop the encoding when retrieving the secret. See code sample below:
my_payload = base64.b64encode(os.urandom(16)) # orignal base64 payload
my_secret = client.secrets.create()
my_secret.payload = my_payload
my_secret.payload_content_type = 'application/octet-stream'
my_secret.payload_content_encoding = 'base64'
my_ref = my_secret.store()
retrieved_secret = client.secrets.get(my_ref)
assert retrieved_secret.payload == my_payload
The assertion fails because the retrieved secret payload is the actual bytes, not the base64 encoded payload we originally give to the client. My expectation is that the thing I give the client should be the same thing I get back, but because of the payload_content_encoding semantics, this is not the case.
A proposed solution would be to deprecate the payload_content_encoding parameter, which will prevent these odd scenarios from happening. This will probably have to be revisited once the content-type blueprint implementation lands. |
When using python-barbicanclient to store a binary blob, if the user pre-encodes the binary in base64, the client will unexpectedly drop the encoding when retrieving the secret. See code sample below:
my_payload = base64.b64encode(os.urandom(16)) # orignal base64 payload
my_secret = client.secrets.create()
my_secret.payload = my_payload
my_secret.payload_content_type = 'application/octet-stream'
my_secret.payload_content_encoding = 'base64'
my_ref = my_secret.store()
retrieved_secret = client.secrets.get(my_ref)
assert retrieved_secret.payload == my_secret.payload
The assertion fails because the retrieved secret payload is the actual bytes, not the base64 encoded payload we originally give to the client. My expectation is that the thing I give the client should be the same thing I get back, but because of the payload_content_encoding semantics, this is not the case.
A proposed solution would be to deprecate the payload_content_encoding parameter, which will prevent these odd scenarios from happening. This will probably have to be revisited once the content-type blueprint implementation lands. |
|
| 2015-03-06 20:01:37 |
Douglas Mendizábal |
python-barbicanclient: status |
New |
In Progress |
|
| 2015-03-06 20:01:42 |
Douglas Mendizábal |
python-barbicanclient: assignee |
|
Douglas Mendizábal (dougmendizabal) |
|
| 2015-03-06 20:01:45 |
Douglas Mendizábal |
python-barbicanclient: importance |
Undecided |
Medium |
|
| 2015-03-06 20:01:49 |
Douglas Mendizábal |
python-barbicanclient: milestone |
|
3.0.3 |
|
| 2015-03-13 20:33:13 |
OpenStack Infra |
python-barbicanclient: status |
In Progress |
Fix Committed |
|
| 2015-03-30 23:01:37 |
Douglas Mendizábal |
python-barbicanclient: status |
Fix Committed |
Fix Released |
|
