| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
Explicitly checks the expiry on the tokens, and rejects tokens that
have expired
had to regenerate the sample data for the tokens as they all had been
generated with values that are now expired.
bug 1179615
Change-Id: Ie06500d446f55fd0ad67ea540c92d8cfc57483f4
|
| |
|
|
|
|
| |
- Regenerate tokens to change expires in expires_at.
Change-Id: Iaa62dca50d34a228e4850b59d263b807c5ee3549
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that the Identity server supports v3 tokens, the auth_token
middleware should permit the in-line validation of such a token. This
essentially means just setting any new environment items
that correspond to the new attributes that may be in a v3 token (such
as domains), as well as allowing for the slight format differences.
Most of the work in this change is actually in the unit tests, where
it was important to try and enable the existing tests to be run against
an auth_token middleware configured for both v2 and v3. This meant
restructing the test class so that the token format is separated
from the individual tests and is initialized by the class Setup().
Since there are some new signed token formats included in this testing,
a new set of the signed tokens was generated.
Fixes Bug #1132390
Change-Id: I78b232d30f5310c39089fbbc8e56c23df291f89f
|
|
|
This step in the process duplicates the auth-token code to keystoneclient but,
for the moment, leaves a copy in its origional location in keystone.
Testing for auth-token is also copied across, as is the cms support file.
Although no other project will yet pick up the code here in the client, since
the paste.ini files haev not yet been updated, it would work if anyone
did reference it.
Once the client code is in, the next step is to update all the other
project paste files, and then finally retire the code from keystone.
Change-Id: I88853a373d406020d54b61cba5a5e887380e3b3e
|
