| 2013-12-10 01:12:35 |
Richard Lee |
bug |
|
|
added bug |
| 2013-12-10 01:18:26 |
OpenStack Infra |
heat: status |
New |
In Progress |
|
| 2013-12-10 01:18:26 |
OpenStack Infra |
heat: assignee |
|
andersonvom (andersonvom) |
|
| 2014-01-10 10:42:11 |
Thomas Herve |
heat: milestone |
|
icehouse-2 |
|
| 2014-01-10 10:42:15 |
Thomas Herve |
heat: importance |
Undecided |
Medium |
|
| 2014-01-21 20:44:35 |
Steve Baker |
heat: milestone |
icehouse-2 |
icehouse-3 |
|
| 2014-01-25 09:28:39 |
OpenStack Infra |
heat: status |
In Progress |
Fix Committed |
|
| 2014-02-20 16:14:31 |
andersonvom |
description |
If I authenticate against keystone separately before heat and pass in the required auth headers, then I should still be able to use heat without having to go through the authtoken middleware.
The authtoken middleware only adds a X-Auth-Url header that is required for the resource clients. The X-Auth-Url doesn't come from keystone, so this should be set elsewhere. |
If I authenticate against keystone separately before heat and pass in the required auth headers, then I should still be able to use heat without having to go through the authtoken middleware.
The authtoken middleware only adds a X-Auth-Url header that is required for the resource clients, so only removing it would break the clients.
Since X-Auth-Url doesn't come from keystone, this logic should be moved to a different middleware to prevent the double authentication mentioned before. |
|
| 2014-02-20 16:15:15 |
andersonvom |
description |
If I authenticate against keystone separately before heat and pass in the required auth headers, then I should still be able to use heat without having to go through the authtoken middleware.
The authtoken middleware only adds a X-Auth-Url header that is required for the resource clients, so only removing it would break the clients.
Since X-Auth-Url doesn't come from keystone, this logic should be moved to a different middleware to prevent the double authentication mentioned before. |
If I authenticate against keystone separately before heat and pass in the required auth headers, then I should still be able to use heat without having to authenticate one more time going through the authtoken middleware.
The authtoken middleware only adds a X-Auth-Url header that is required for the resource clients, so only removing it would break the clients.
Since X-Auth-Url doesn't come from keystone, this logic should be moved to a different middleware to prevent the double authentication mentioned before. |
|
| 2014-02-20 16:16:27 |
Richard Lee |
description |
If I authenticate against keystone separately before heat and pass in the required auth headers, then I should still be able to use heat without having to authenticate one more time going through the authtoken middleware.
The authtoken middleware only adds a X-Auth-Url header that is required for the resource clients, so only removing it would break the clients.
Since X-Auth-Url doesn't come from keystone, this logic should be moved to a different middleware to prevent the double authentication mentioned before. |
If I authenticate against keystone separately before heat and pass in the required auth headers, then I should still be able to use heat without having to authenticate one more time going through the authtoken middleware.
The authtoken middleware adds a X-Auth-Url header that is required for the resource clients, so removing it would break the clients.
Since X-Auth-Url doesn't come from keystone, this logic should be moved to a different middleware to prevent having to double authenticate as mentioned before. |
|
| 2014-02-20 16:17:32 |
Richard Lee |
description |
If I authenticate against keystone separately before heat and pass in the required auth headers, then I should still be able to use heat without having to authenticate one more time going through the authtoken middleware.
The authtoken middleware adds a X-Auth-Url header that is required for the resource clients, so removing it would break the clients.
Since X-Auth-Url doesn't come from keystone, this logic should be moved to a different middleware to prevent having to double authenticate as mentioned before. |
If I authenticate against keystone separately before heat and pass in the required auth headers, then I should still be able to use heat without having to authenticate one more time going through the authtoken middleware.
The authtoken middleware adds a X-Auth-Url header that is required for the resource clients, so removing the middleware, even if all keystone auth headers are passed into heat, would break the clients.
Since X-Auth-Url doesn't come from keystone, this logic should be moved to a different middleware to prevent having to double authenticate as mentioned before. |
|
| 2014-03-05 20:08:15 |
Thierry Carrez |
heat: status |
Fix Committed |
Fix Released |
|
| 2014-04-17 10:20:37 |
Thierry Carrez |
heat: milestone |
icehouse-3 |
2014.1 |
|
