Currently the api ref states the return code for
GET /v3/auth/catalog returns 204 no content. However
after testing the return code is 200 ok. This commit
updates api-ref to correct return code.
Change-Id: I5f1049b565b1e11fb6e748b43ae9dfe1e16250a6
Closes-Bug: 1670380
Sphinx 1.5 complains about "Could not lex literal_block as "json".
Highlighting skipped." - and fails to build.
Change the problematic code to use javascript for highlighting - it's
only a json snippet, not a full json file.
Change-Id: I65558119dcc166bd25f12568b480498cac80c653
Only x-auth-token is required for these api calls, but the
api-ref mentions x-subject-token as required also.
This fixes that by removing x-subject-token from the call docs.
Change-Id: Ib30a71b81939b11363aced4aecd545049c210380
Closes-Bug: 1667194
Basically, the commit removes the file encoding - since jenkins is fine
with it, means it was really unnecessary and the change makes sense.
Change-Id: I0d97104b173b00a383955b5ad5b597e4c6a19780
This patch removes any unused parameters in the v2 and v3 api's.
In order to find which parameters were unused, I wrote a script
that found all the parameters used in the `parameters.yaml` files,
then is searched the same api directory (ex: v3/, v3-ext/, etc.)
for any reference to these parameters. Anything unreferenced was
flagged and then removed.
Script: http://cdn.pasteraw.com/8cdh0e76aqhtliuh874veautr7as8k7
Change-Id: I1558ac94e1041f9fbb1d6713b394c4f97f997ada
Some parameters of similar name would follow the convention
such as `region_id` and `region_id_1` which gave no good
information as to the differences.
This patch changes these names to help give such information.
Change-Id: I2dec61ed06042990ff54e86c02dc3fca9d566366
As per the bug, 'name' and 'nme' are not part of the 'endpoint'
table and were being assigned to the 'extras' column. This is
why they are not being validated.
The endpoint docs also show that `region_id` is not optional, even
though it is. This updates the docs to reflect optional `region_id`.
Closes-Bug: #1579014
Change-Id: I085b75c59767eb96b3bdfe3b887e5e2639122a34
The openstack.org pages now support https and our references to
the site should by default be one signed by the organization.
Change-Id: I30a462e03d1fd7852511e22cac34c6bc0e8917f4
There were a couple comments about making minor changes in the patch
set for changing change_password to not require a token. These comments
mentioned fixing the wording on the change_user api-ref note and
adding an additional assertion for one of the added unit tests.
https://review.openstack.org/#/c/404022/
This change corrects the wording in the api-ref note for
change_password about not needing an authentication token and
adds an additional assertion for changing an expired password to
verify that once an expired password is successfully changed, the
user is able to authenticate and create a token.
Change-Id: I8e557d344ee77e0c9c28391d3ef09913bd87fef6
This patch adds filters to list_user that enable the user to query for
unique_id, idp_id, protocol_id, or a mix of these to get back the
corresponding users of the federated attributes.
Partially-Implements: bp support-federated-attr
Change-Id: Iea5681791e521e9b8d96137fe30c388c10a02b30
Currently, if a users password expires, they must contact an
administrator in order to have their password reset for them.
This change allows a user to perform the change_password call
without a token, which will allow a user with an expired password
to change it if they are using PCI-DSS related features. This
removes the issue of needing an administrator to reset any
user's password that has expired.
Also updated the api-ref with the related changes.
Change-Id: I4d3421c56642cfdbb25cb33b3aaaacbac4c64dd1
Closes-Bug: #1641645
This change builds on the previous one by cleaning up all the wording
around associations and makes them consistent regardless of the
associations being direct or via endpoint groups.
Change-Id: I9582c5e8dbb83c37abcb432835dd7b609bd7841c
Closes-Bug: 1654613
The OS-EP-FILTER documentation needed some work. The wording around
several of the examples didn't make a whole lot of sense. And some of
the requests were copy/pastes from other examples.
This change attempts to clarify the need for endpoint groups and how
they can be useful. This patch also moves the endpoint group CRUD
documentation to the beginning of the section, which leaves the rest
of the section to explain how to associate projects to endpoints
directly or use endpoint groups. Previously, the endpoint group CRUD
was in the middle of the section and made the flow the document jump
around a bit.
Change-Id: I1f6cbecc5c3a4c8e86a73a3cfed4b9a09e43b31f
Partial-Bug: 1654613
An Identity Provider (IdP) should be mapped to a domain. This patch
updates the documentation and creates a release note recommending the
domain_id parameter.
Depends-On: Id18b8b2fe853b97631bc990df8188ed64a6e1275
Partial-Bug: #1642687
Change-Id: I1cb749371175169662dbb5fa8feafe403fb1c39b
The ability to list endpoint associations for projects only requires
the project ID as a parameter. The documentation was advertising that
the endpoint ID was also required, which seems like a rogue
copy/paste.
Change-Id: I2101ebaab0bdcbc9347e854dbe7f522c1c6320e8
The sample request and simplified representation was incorrect.
Change the sample to match the result, the sample was used in
other spots but did not affect the other APIs.
Also fixed the sentence describing valid filters that can be
used; only `region_id` is supported, not `region` [1].
[1] e49a95ff6e/keystone/catalog/controllers.py (L484)
Change-Id: Id460b85d37acc0cba9246ace6a338a315080b10b
The token issue response has timestamps like this:
"issued_at": "2017-01-03T22:42:55.000000Z"
"expires_at": "2017-01-03T23:42:55.000000Z"
Which didn't match the format documented in the API spec (the
response has subsecond precision and Z rather than ±HHMM).
Change-Id: I1deeac1776a7716ee66d187d1c1c7c1f5b02235f
Closes-Bug: 1634568
The v3 API spec for tokens documents the format of timestamps.
It says the format is like "CCYY-MM-DDThh:mm:ss±hh:mm".
By this, the timestamps returned by keystone like this:
2016-12-13T15:33:12+0000
Change-Id: I616865c1b12457487c4aeb5b8e907ca01cb79ef9
Closes-Bug:#1634568
New proposal on how we document the password_expires_at query.
bp pci-dss-query-password-expired-users
Co-Authored-By: Samuel Pilla <sp516w@att.com>
Change-Id: I81facd0a84f5c05f72294eb1a143c7632b2406e1
The api documentation for the following queries:
/v3/users?password_expires_at={operator}:{timestamp}
/v3/groups/{group_id}/users?password_expires_at={operator}:{timestamp}
The acceptable operators are lt, lte, gt, gte, eq, and neq.
They allow for querying for a range of timestamps rather than
an exact time for password expiration.
Examples:
- GET /v3/users?password_expires_at=lt:2016-11-06T15:32:17Z
- GET /v3/groups/079c578fd99b428ab61fcd4c9bd88ecd/users?password_expires_at=gt:2016-12-08T22:02:00Z
Partially-Implements: bp pci-dss-query-password-expired-users
Parent-Id: If0b9cc3c8af92b2ea5d41a0e8afeb78e12b7689c
Change-Id: I737dd6b703cc5af16b3d748ebaeebe0fbada039e
Updates the api-ref to reflect that list_role_assignment now also
return the donain id and name for roles.
Related-Bug: #1607114
Change-Id: Ie887907b9410e84b5f3ff958b05b2fd98efbe5aa
GET /role_assignments do not list the effective role_assignments,
this is done via the "effective" query param as described in the
doc.
For listing role assignments, we also have a similar explanation in
the "roles.inc" doc. After giving some thought, I guess the best option
is to leave both entries. This can sound redundant, but both entries give
pertinent explanation to the doc they are part of. For example, in the
"inherit.inc" doc, we have a introduction to the GET /role_assignments
API and explanations about the "effective", "include_subtree" and
"inherit_to" query parameters, which are essentially part of the
inherited roles feature.
Closes-Bug: 1645554
Change-Id: I38fa771295a1e1f482b10013f922a0bd0e432f8d
When reading the OS-FEDERATION API documentation, it is not clear how
to find the ID of the token when requesting either an unscoped or
scoped token. Token requests for the OS-FEDERATION API work the same
way as for the standard API, which is that the token ID is returned in
the X-Subject-Token header, so let's just mention that in the
OS-FEDERATION API documentation.
Change-Id: I6e9743d9001684f0d05ace119509f643c8b8e363
A service user from auth_token middleware should be able to fetch a
token that has expired within a certain window so that long running
operations can finish.
Implements bp: allow-expired
Change-Id: I784f719be88481048f5aa7a79d34a54907438cf3
Changed the new password value in the JSON request for
V3 "Change User Password" example to be more clear about which field
the "new" password should be in and that the user's password will be
that "new" password.
Change-Id: I6790422956ed99f90fd41b6774bd266fd57d7130
The v3 endpoint documentation /v3/auth/tokens/OS-PKI/revoked is missing
in /api-ref. This patch set adds the documentation for v3.
A separate patch set will be submitted for v2.
Change-Id: I3db3356d24cc8885012756016a90a0996fcf14f5
Partial-Bug: #1626778