Bases: testtools.testcase.TestCase
Light weight base test class.
This is a placeholder that will eventually go away once the setup/teardown in TestCase is properly trimmed down to the bare essentials. This is really just a play to speed up the tests by eliminating unnecessary work.
Bases: object
A mixin for consolidating sql-specific test overrides.
Add this versioned driver to the list that will be loaded.
| Parameters: |
|
|---|
This method assumes that versioned drivers are named: <version_suffix><name of versionless driver>, e.g. ‘V8_backends’.
Bases: keystone.tests.unit.core.BaseTestCase
Asserts that two datetimes are nearly equal within a small delta.
| Parameters: | delta – Maximum allowable time delta, defined in seconds. |
|---|
Asserts that the message in a raised exception matches a regexp.
Override to load managers that aren’t loaded by default.
This is useful to load managers initialized by extensions. No extra backends are loaded by default.
| Returns: | dict of name -> manager |
|---|
Create a user via the API. Keep the created password.
The password is saved and restored when api.create_user() is called. Only use this routine if there is a requirement for the user object to have a valid password after api.create_user() is called.
Define an endpoint_ref having a pre-3.2 form.
Contains the deprecated ‘region’ instead of ‘region_id’.
This decorator is used to skip a test if caching is disabled.
Caching can be disabled either globally or for a specific section.
In the code fragment:
@skip_if_cache_is_disabled('assignment', 'token')
def test_method(*args):
...
The method test_method would be skipped if caching is disabled globally via the enabled option in the cache section of the configuration or if the caching option is set to false in either assignment or token sections of the configuration. This decorator can be used with no arguments to only check global caching.
If a specified configuration section does not define the caching option, this decorator makes the same assumption as the should_cache_fn in keystone.common.cache that caching should be enabled.
Fake LDAP server for test harness.
This class does very little error checking, and knows nothing about ldap class definitions. It implements the minimum emulation of the python ldap library to work with keystone.
Bases: keystone.common.ldap.core.LDAPHandler
Emulate the python-ldap API.
The python-ldap API requires all strings to be UTF-8 encoded. This is assured by the caller of this interface (i.e. KeystoneLDAPHandler).
However, internally this emulation MUST process and store strings in a canonical form which permits operations on characters. Encoded strings do not provide the ability to operate on characters. Therefore this emulation accepts UTF-8 encoded strings, decodes them to unicode for operations internal to this emulation, and encodes them back to UTF-8 when returning values from the emulation.
Modify the object at dn using the attribute list.
| Parameters: |
|
|---|
Execute async request
Only msgid param is supported. Request info is fetched from global variable PendingRequests by msgid, executed using search_s and limited if requested.
Search for all matching objects under base using the query.
Args: base – dn to search under scope – search scope (base, subtree, onelevel) filterstr – filter objects by attrlist – attrs to return. Returns all attrs if not specified
Bases: keystone.tests.unit.fakeldap.FakeLdap
FakeLdap subclass that does not support subtree delete
Same as FakeLdap except delete will throw the LDAP error ldap.NOT_ALLOWED_ON_NONLEAF if there is an attempt to delete an entry that has children.
Bases: keystone.tests.unit.fakeldap.FakeLdap
Emulate the python-ldap API with pooled connections.
This class is used as connector class in PooledLDAPHandler.
Fixtures for Federation Mapping.
Bases: keystone.tests.unit.core.TestCase
Performs restful tests against the WSGI app over HTTP.
This class launches public & admin WSGI servers for every test, which can be accessed by calling public_request() or admin_request(), respectfully.
restful_request() and request() methods are also exposed if you need to bypass restful conventions or access HTTP details in your test implementation.
Three new asserts are provided:
unless an expected_status is provided
if an expected_status is provided
appear as expected
Requests are automatically serialized according to the defined content_type. Responses are automatically deserialized as well, and available in the response.body attribute. The original body content is available in the response.raw attribute.
Asserts a specific status code on the response.
| Parameters: |
|
|---|
example:
self.assertResponseStatus(response, http_client.NO_CONTENT)
Asserts that a status code lies inside the 2xx range.
| Parameters: | response – httplib.HTTPResponse to be verified to have a status code between 200 and 299. |
|---|
example:
self.assertResponseSuccessful(response)
Verify that the error response is valid.
Subclasses can override this function based on the expected response.
Convenience method so that we can test authenticated requests.
Bases: keystone.tests.unit.test_associate_project_endpoint_extension.EndpointFilterTestCase
HEAD /OS-EP-FILTER/projects/{project_id}/endpoints/{endpoint_id}
Valid project and endpoint id test case.
HEAD /OS-EP-FILTER/projects/{project_id}/endpoints/{endpoint_id}
Invalid endpoint id test case.
HEAD /OS-EP-FILTER/projects/{project_id}/endpoints/{endpoint_id}
Invalid project id test case.
PUT /OS-EP-FILTER/projects/{project_id}/endpoints/{endpoint_id}
Valid endpoint and project id test case.
PUT /OS-EP-FILTER/projects/{project_id}/endpoints/{endpoint_id}
Invalid endpoint id test case.
PUT OS-EP-FILTER/projects/{project_id}/endpoints/{endpoint_id}
Invalid project id test case.
PUT /OS-EP-FILTER/projects/{project_id}/endpoints/{endpoint_id}
Unexpected body in request. The body should be ignored.
GET /OS-EP-FILTER/projects/{project_id}/endpoints
Invalid project id test case.
GET /OS-EP-FILTER/projects/{project_id}/endpoints
Valid project and endpoint id test case.
GET /OS-EP-FILTER/endpoints/{endpoint_id}/projects
Valid endpoint-project association test case.
GET /OS-EP-FILTER/endpoints/{endpoint_id}/projects
Invalid endpoint id test case.
GET /OS-EP-FILTER/endpoints/{endpoint_id}/projects
Valid endpoint id but no endpoint-project associations test case.
DELETE /OS-EP-FILTER/projects/{project_id}/endpoints/{endpoint_id}
Valid project id and endpoint id test case.
Bases: keystone.tests.unit.test_associate_project_endpoint_extension.EndpointFilterTestCase
Verify endpoints from default scoped token filtered.
Verify an invalid endpoint-project association is handled.
Bases: keystone.tests.unit.test_associate_project_endpoint_extension.EndpointFilterTestCase
Create a valid endpoint group and project association.
Create an invalid endpoint group and project association.
HEAD /OS-EP-FILTER/endpoint_groups/{endpoint_group_id}
Valid endpoint_group_id test case.
Test HEAD with a valid endpoint group and project association.
Test HEAD with an invalid endpoint group and project association.
HEAD /OS-EP-FILTER/endpoint_groups/{endpoint_group_id}
Invalid endpoint_group_id test case.
POST /OS-EP-FILTER/endpoint_groups
Valid endpoint group test case.
POST /OS-EP-FILTER/endpoint_groups
Invalid endpoint group creation test case.
GET /OS-EP-FILTER/endpoint_groups/{endpoint_group}
Valid endpoint group test case.
GET /OS-EP-FILTER/endpoint_groups/{endpoint_group}
Invalid endpoint group test case.
Test when no endpoint groups associated with the project.
GET /OS-EP-FILTER/endpoint_groups/{endpoint_group}
Valid endpoint group test case.
GET /OS-EP-FILTER/endpoint_groups/{endpoint_group}
Invalid endpoint group test case.
Test retrieving project endpoint group association.
GET /OS-EP-FILTER/projects/{project_id}/endpoint_groups.
GET /OS-EP-FILTER/endpoint_groups/{endpoint_group}/endpoints
Valid endpoint group test case.
GET /OS-EP-FILTER/projects/{project_id}/endpoints
Valid project, endpoint id, and endpoint group test case.
GET /OS-EP-FILTER/endpoint_groups/{endpoint_group}/projects
Valid endpoint group test case.
PATCH /OS-EP-FILTER/endpoint_groups/{endpoint_group}
Valid endpoint group patch test case.
PATCH /OS-EP-FILTER/endpoint_groups/{endpoint_group}
Valid endpoint group patch test case.
Bases: keystone.tests.unit.test_associate_project_endpoint_extension.EndpointFilterTestCase, keystone.tests.unit.test_v3.JsonHomeTestMixin
Bases: keystone.tests.unit.test_auth.AuthTest
Verify sending empty json dict raises the right exception.
Verify authenticate to a project with unsafe name fails.
Verify sending invalid ‘auth’ raises the right exception.
Verify sending large ‘password’ raises the right exception.
Verify sending large ‘tenantId’ raises the right exception.
Verify sending large ‘tenantName’ raises the right exception.
Verify sending large ‘token’ raises the right exception.
Verify sending large ‘userId’ raises the right exception.
Verify sending large ‘username’ raises the right exception.
Verify that empty username and userID raises ValidationError.
Bases: keystone.tests.unit.core.SQLDriverOverrides, keystone.tests.unit.test_auth.AuthTest
Tests for the catalog provided in the auth response.
Bases: keystone.tests.unit.test_auth.AuthTest
Authenticating with an invalid project fails.
Authenticating with an invalid project fails.
Verify getting an unscoped token with an unscoped token.
Bases: keystone.tests.unit.test_auth.AuthTest
Verify that trust can be created without project id.
Also, token can be generated with that trust.
Bases: keystone.tests.unit.core.SQLDriverOverrides, keystone.tests.unit.core.TestCase
Bases: object
Create sample data to test policy associations.
The following data is created:
Bases: keystone.tests.unit.test_backend_sql.SqlModels
Set of tests for checking SQL Policy Association Mapping.
Bases: keystone.tests.unit.test_backend_sql.SqlTests, keystone.tests.unit.test_backend_endpoint_policy.PolicyAssociationTests
Bases: keystone.tests.unit.test_backend_sql.SqlModels
Set of tests for checking SQL Federation.
Bases: keystone.tests.unit.test_backend_sql.SqlModels
Set of tests for checking SQL Identity ID Mapping.
Bases: keystone.tests.unit.core.TestCase, keystone.tests.unit.token.test_backends.TokenTests
Bases: keystone.tests.unit.core.TestCase, keystone.tests.unit.token.test_backends.TokenCacheInvalidation
Bases: keystone.tests.unit.identity.test_backends.IdentityTests, keystone.tests.unit.assignment.test_backends.AssignmentTests, keystone.tests.unit.resource.test_backends.ResourceTests
Multiple domains are not supported.
Multiple domains are not supported.
List group members with deleted user.
If a group has a deleted entry for a member, the non-deleted members are returned.
Multiple domain assignments are not supported.
Multiple domain assignments are not supported.
Bases: object
Mixin class with support methods for domain-specific config testing.
Bases: keystone.tests.unit.test_backend_ldap.BaseLDAPIdentity, keystone.tests.unit.core.SQLDriverOverrides, keystone.tests.unit.core.TestCase, keystone.tests.unit.test_backend_ldap.BaseMultiLDAPandSQLIdentity
Class to test when all domains use specific configs, including SQL.
We define a set of domains and domain-specific backends:
Although the default driver still exists, we don’t use it.
Test that separate configs have segregated the domain.
Test Plan:
Bases: keystone.tests.unit.test_backend_ldap.DomainSpecificLDAPandSQLIdentity
Class to test simplest use of domain-specific SQL driver.
The simplest use of an SQL domain-specific backend is when it is used to augment the standard case when LDAP is the default driver defined in the main config file. This would allow, for example, service users to be stored in SQL while LDAP handles the rest. Hence we define:
Bases: keystone.tests.unit.test_backend_ldap.BaseLDAPIdentity, keystone.tests.unit.core.TestCase
Bases: keystone.tests.unit.core.TestCase, keystone.tests.unit.identity.test_backends.LimitTests
Bases: keystone.tests.unit.identity.test_backends.FilterTests, keystone.tests.unit.core.TestCase
Bases: keystone.tests.unit.test_backend_ldap.BaseLDAPIdentity, keystone.tests.unit.core.SQLDriverOverrides, keystone.tests.unit.core.TestCase
Class to test mapping of default LDAP backend.
The default configuration is not to enable mapping when using a single backend LDAP driver. However, a cloud provider might want to enable the mapping, hence hiding the LDAP IDs from any clients of keystone. Setting backward_compatible_ids to False will enable this mapping.
Test to ensure entities not create via controller are mapped.
Many LDAP backends will, essentially, by Read Only. In these cases the mapping is not built by creating objects, rather from enumerating the entries. We test this here my manually deleting the mapping and then trying to re-read the entries.
Bases: keystone.tests.unit.test_backend_ldap.BaseLDAPIdentity, keystone.tests.unit.core.SQLDriverOverrides, keystone.tests.unit.core.TestCase, keystone.tests.unit.test_backend_ldap.BaseMultiLDAPandSQLIdentity
Class to test common SQL plus individual LDAP backends.
We define a set of domains and domain-specific backends:
Normally one would expect that the default domain would be handled as part of the “other domains” - however the above provides better test coverage since most of the existing backend tests use the default domain.
Enable the chosen form of multi domain configuration support.
This method enables the file-based configuration support. Child classes that wish to use the database domain configuration support should override this method and set the appropriate config_fixture option.
Test that separate configs have segregated the domain.
Test Plan:
Test that ‘uni-domain’ created IDs still work.
Throwing the switch to domain-specific backends should not cause existing identities to be inaccessible via ID.
Test the Manager class scans the config directory.
The setup for the main tests above load the domain configs directly so that the test overrides can be included. This test just makes sure that the standard config directory scanning does pick up the relevant domain config files.
Bases: keystone.tests.unit.test_backend_ldap.MultiLDAPandSQLIdentity
Class to test the use of domain configs stored in the database.
Repeat the same tests as MultiLDAPandSQLIdentity, but instead of using the domain specific config files, store the domain specific values in the database.
Ensure registration is deleted when a domain is deleted.
Ensure database domain configs have no effect if disabled.
Set reading from database configs to false, restart the backends and then try and set and use database configs.
Ensure we self heal an orphaned sql registration.
Ensure domain drivers are reloaded on a config modification.
Bases: keystone.tests.unit.test_backend_ldap_pool.LdapPoolCommonTestMixin, keystone.tests.unit.test_backend_ldap.LDAPIdentity, keystone.tests.unit.core.TestCase
Executes tests in existing base class with pooled LDAP handler.
Bases: keystone.tests.unit.core.TestCase, keystone.tests.unit.policy.test_backends.PolicyTests
Bases: sqlalchemy.ext.declarative.api.Base
Bases: keystone.tests.unit.test_backend_sql.SqlTests, keystone.tests.unit.catalog.test_backends.CatalogTests
Bases: keystone.tests.unit.test_backend_sql.SqlTests, keystone.tests.unit.identity.test_backends.FilterTests
Bases: keystone.tests.unit.test_backend_sql.SqlTests, keystone.tests.unit.identity.test_backends.IdentityTests, keystone.tests.unit.assignment.test_backends.AssignmentTests, keystone.tests.unit.resource.test_backends.ResourceTests
Ensure we cannot access the hidden root of all project domains.
Calling any of the driver methods should result in the same as would be returned if we passed a project that does not exist. We don’t test create_project, since we do not allow a caller of our API to specify their own ID for a new entity.
Test that inherited roles on the domain are excluded.
Test Plan:
Test the special storage of domain_id=None in sql resource driver.
The resource driver uses a special value in place of None for domain_id in the project record. This shouldn’t escape the driver. Hence we test the interface to ensure that you can store a domain_id of None, and that any special value used inside the driver does not escape through the interface.
This tests for backwards-compatibility with an essex/folsom bug.
Non-indexed attributes were returned in an ‘extra’ attribute, instead of on the entity itself; for consistency and backwards compatibility, those attributes should be included twice.
This behavior is specific to the SQL driver.
This tests for backwards-compatibility with an essex/folsom bug.
Non-indexed attributes were returned in an ‘extra’ attribute, instead of on the entity itself; for consistency and backwards compatibility, those attributes should be included twice.
This behavior is specific to the SQL driver.
Bases: keystone.tests.unit.test_backend_sql.SqlTests, keystone.tests.unit.assignment.test_backends.ImpliedRoleTests
Bases: keystone.tests.unit.test_backend_sql.SqlTests, keystone.tests.unit.assignment.test_backends.InheritanceTests
Bases: keystone.tests.unit.test_backend_sql.SqlTests, keystone.tests.unit.identity.test_backends.LimitTests
Bases: keystone.tests.unit.test_backend_sql.SqlTests
Assert that a table’s schema is what we expect.
| Parameters: |
|
|---|---|
| Raises AssertionError: | |
when the database schema doesn’t match the expected schema |
|
The expected_schema format is simply:
(
('column name', sql type, qualifying detail),
...
)
The qualifying detail varies based on the type of the column:
- sql.Boolean columns must indicate the column's default value or
None if there is no default
- Columns with a length, like sql.String, must indicate the
column's length
- All other column types should use None
Example:
cols = (('id', sql.String, 64),
('enabled', sql.Boolean, True),
('extra', sql.JsonBlob, None))
self.assertExpectedSchema('table_name', cols)
Bases: keystone.tests.unit.test_backend_sql.SqlTests, keystone.tests.unit.policy.test_backends.PolicyTests
Bases: keystone.tests.unit.core.SQLDriverOverrides, keystone.tests.unit.core.TestCase
Bases: keystone.tests.unit.test_backend_sql.SqlTests, keystone.tests.unit.token.test_backends.TokenTests
Bases: keystone.tests.unit.test_backend_sql.SqlTests, keystone.tests.unit.token.test_backends.TokenCacheInvalidation
Bases: keystone.tests.unit.test_backend_sql.SqlTests, keystone.tests.unit.trust.test_backends.TrustTests
Bases: keystone.tests.unit.core.TestCase, keystone.tests.unit.catalog.test_backends.CatalogTests
Bases: keystone.tests.unit.rest.RestfulTestCase
Test the invalid cases: substitutions is not exactly right.
Create endpoint with valid URL should be tested, too.
Test pure v3 endpoint can be fetched via v2.0 API.
For those who are using v2.0 APIs, endpoints created by v3 API should also be visible as there are no differences about the endpoints except the format or the internal implementation. Since publicURL is required for v2.0 API, so only v3 endpoints of the service which have the public interface endpoint will be converted into v2.0 endpoints.
Test that the v2.0 API can’t fetch v3 endpoints without publicURLs.
v2.0 API will return endpoints created by v3 API, but publicURL is required for the service in the v2.0 API, therefore v3 endpoints of a service which don’t have publicURL will be ignored.
Bases: keystone.tests.unit.core.SQLDriverOverrides, keystone.tests.unit.core.TestCase
Bases: keystone.tests.unit.core.SQLDriverOverrides, keystone.tests.unit.core.TestCase
Bases: keystone.tests.unit.test_cli.CliDomainConfigAllTestCase
Bases: keystone.tests.unit.test_cli.CliDomainConfigAllTestCase
Bases: keystone.tests.unit.test_cli.CliDomainConfigAllTestCase
Bases: keystone.tests.unit.test_cli.CliDomainConfigAllTestCase
Bases: keystone.tests.unit.core.SQLDriverOverrides, keystone.tests.unit.core.TestCase
Bases: keystone.tests.unit.core.TestCase
Test using the deprecated AND new name for renamed options.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Bases: keystone.tests.unit.core.TestCase
Checking if user is admin causes uncaught error.
When checking if a user is an admin, keystone.exception.Unauthorized is raised but not caught if the user is not an admin.
Test signature validation with the access/secret provided.
Signature is not presented in signature reference data.
Test signature validation when host is bound with port.
Host is bound with a port, generally, the port here is not the standard port for the protocol, like ‘80’ for HTTP and port 443 for HTTPS, the port is not omitted by the client library.
Test signature validation when host is bound with well-known port.
Host is bound with a port, but the port is well-know port like ‘80’ for HTTP and port 443 for HTTPS, sometimes, client library omit the port but then make the request with the port. see (How to create the string to sign): ‘http://docs.aws.amazon.com/ general/latest/gr/signature-version-2.html’.
Since “credentials[‘host’]” is not set by client library but is taken from “req.host”, so caused the differences.
Bases: keystone.tests.unit.test_exception.ExceptionTestCase
Tests whether security-related info is exposed to the API user.
Bases: keystone.tests.unit.test_exception.ExceptionTestCase
Tests if internal info is exposed to the API user on UnexpectedError.
Bases: keystone.exception.UnexpectedError
Bases: keystone.tests.unit.test_hacking_checks.BaseStyleCheck
Bases: keystone.tests.unit.test_hacking_checks.BaseStyleCheck
Bases: keystone.tests.unit.test_hacking_checks.BaseStyleCheck
Bases: keystone.tests.unit.test_hacking_checks.BaseLoggingCheck
Bases: keystone.tests.unit.test_hacking_checks.BaseStyleCheck
Bases: keystone.tests.unit.test_hacking_checks.BaseLoggingCheck
Bases: keystone.tests.unit.test_hacking_checks.BaseStyleCheck
Bases: keystone.tests.unit.test_hacking_checks.BaseLoggingCheck
Bases: keystone.tests.unit.test_kvs.KVSBackendFixture
Bases: dogpile.cache.proxy.ProxyBackend
A test dogpile.cache proxy that does nothing.
Bases: dogpile.cache.proxy.ProxyBackend
A test dogpile.cache proxy that does nothing.
Bases: dogpile.cache.api.CacheBackend
A test dogpile.cache backend.
This test backend conforms to the mixin-mechanism for overriding set and set_multi methods on dogpile memcached drivers.
Bases: keystone.tests.unit.test_backend_ldap_pool.LdapPoolCommonTestMixin, keystone.tests.unit.test_ldap_livetest.LiveLDAPIdentity
Executes existing LDAP live test with pooled LDAP handler.
Also executes common pool specific tests via Mixin class.
Bases: keystone.tests.unit.test_ldap_livetest.LiveLDAPIdentity
Bases: keystone.tests.unit.test_middleware.MiddlewareRequestTestBase
alias of AdminTokenAuthMiddleware
Bases: keystone.tests.unit.test_backend_sql.SqlTests, keystone.tests.unit.test_middleware.MiddlewareRequestTestBase
alias of AuthContextMiddleware
Verify ephemeral user does not need a specified user.
Keystone is not looking to match the user, but a corresponding group.
Bases: keystone.tests.unit.test_middleware.MiddlewareRequestTestBase
alias of JsonBodyMiddleware
Bases: keystone.tests.unit.core.TestCase
Bases: keystone.tests.unit.test_backend_sql.SqlTests, keystone.tests.unit.test_revoke.RevokeTests
To run these tests against a live database:
Modify the file keystone/tests/unit/config_files/backend_sql.conf to use the connection for your live database.
Set up a blank, live database.
Run the tests using:
tox -e py27 -- keystone.tests.unit.test_sql_migrate_extensions
WARNING:
Your database will be wiped.
Do not do this against a Database with valuable data as
all data will be lost.
Bases: keystone.tests.unit.test_sql_upgrade.SqlMigrateBase
Bases: keystone.tests.unit.test_sql_upgrade.SqlMigrateBase
Bases: keystone.tests.unit.test_sql_upgrade.SqlMigrateBase
Bases: keystone.tests.unit.test_sql_upgrade.SqlMigrateBase
To run these tests against a live database:
Modify the file keystone/tests/unit/config_files/backend_sql.conf to use the connection for your live database.
Set up a blank, live database
Run the tests using:
tox -e py27 -- keystone.tests.unit.test_sql_upgrade
WARNING:
Your database will be wiped.
Do not do this against a database with valuable data as
all data will be lost.
Bases: keystone.tests.unit.core.SQLDriverOverrides, keystone.tests.unit.core.TestCase
Asserts that the table contains the expected set of columns.
Bases: keystone.tests.unit.test_sql_upgrade.SqlMigrateBase
Naively inserts key-value pairs into a table, given a dictionary.
Check database upgraded successfully for domain specific roles.
The following items need to be checked:
Bases: keystone.tests.unit.core.TestCase
Make sure both public and admin API work with 1-way ipv6 & SSL.
Bases: keystone.tests.unit.core.TestCase
Test binding tokens to a Principal.
Even though everything in this file references kerberos the same concepts will apply to all future binding mechanisms.
Bases: keystone.tests.unit.test_token_provider.PKIProviderTests, keystone.tests.unit.core.TestCase
Bases: keystone.tests.unit.test_token_provider.PKIProviderTests, keystone.tests.unit.core.TestCase
Bases: object
Fakes a WSGI app URL normalized.
Bases: object
Helper method to assert No Roles
This needs to be overridden by child classes based on their content type.
Bases: object
Tests to show the broken username behavior in V2.
The V2 API is documented to use username instead of name. The API forced used to use name and left the username to fall into the extra field.
These tests ensure this behavior works so fixes to username/name will be backward compatible.
Creates a users and returns the response object.
| Parameters: | user_attrs – attributes added to the request body (optional) |
|---|
The response for creating a user will contain the extra fields.
The response for getting a user will contain the extra fields.
The response for updating a user will contain the extra fields.
This is specifically testing for updating a username when a value was not previously set.
The response for updating a user will contain the extra fields.
This tests updating a username that was previously set.
Username is set as the value of name if no username is provided.
This matches the v2.0 spec where we really should be using username and not name.
Username is set as the value of name if no username is provided.
This matches the v2.0 spec where we really should be using username and not name.
Username is set as the value of name if no username is provided.
This matches the v2.0 spec where we really should be using username and not name.
Bases: keystone.tests.unit.test_v2.RestfulTestCase, keystone.tests.unit.test_v2.CoreApiTests, keystone.tests.unit.test_v2.LegacyV2UsernameTests
Hash for tokens in revocation list and server config should match.
If the server is configured for md5, then the revocation list has tokens hashed with MD5.
Hash for tokens in revocation list and server config should match.
If the server is configured for sha256, then the revocation list has tokens hashed with SHA256.
Bases: keystone.tests.unit.core.TestCase
Tests for the V2 Tenant controller.
These tests exercise keystone.assignment.controllers.Tenant.
Test that the creation of a project acting as a domain fails.
Test that passing is_domain=False is not allowed.
Test that delete is_domain project is not allowed in v2.
Test that get project does not return is_domain projects.
get_project_users when user doesn’t exist.
When a user that’s not known to identity has a role on a project, then get_project_users just skips that user.
Test v2 get_all_projects having projects that act as a domain.
In v2 no project with the is_domain flag enabled should be returned.
Bases: object
To hold assignment helper functions.
Build and return a role assignment entity with provided attributes.
Provided attributes are expected to contain: domain_id or project_id, user_id or group_id, role_id and, optionally, inherited_to_projects.
Build and return a role assignment entity with provided attributes.
The expected attributes are: domain_ref or project_ref, user_ref or group_ref, role_ref and, optionally, inherited_to_projects.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Bases: object
To hold auth building helper functions.
Build auth dictionary.
It will create an auth dictionary based on all the arguments that it receives.
Bases: object
JSON Home test
Mixin this class to provide a test for the JSON-Home response for an extension.
The base class must set JSON_HOME_DATA to a dict of relationship URLs (rels) to the JSON-Home data for the relationship. The rels and associated data must be in the response.
Bases: keystone.tests.unit.core.SQLDriverOverrides, keystone.tests.unit.rest.RestfulTestCase, keystone.tests.common.auth.AuthTestMixin
Assert that two tokens are equal.
Compare two tokens except for their ids. This also truncates the time in the comparison.
Make assertions common to all API entities.
If a reference is provided, the entity will also be compared against the reference.
Make assertions common to all API list responses.
If a reference is provided, it’s ID will be searched for in the response, and asserted to be equal.
Make assertions common to all API responses.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test inheritance crud and its effects.
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.test_v3.AssignmentTestMixin
Test inheritance crud and its effects.
Call GET /role_assignments?scope.OS-INHERIT:inherited_to.
Test Plan:
Call GET /role_assignments?effective.
Test Plan:
Get role_assignment ?project_id=X?include_subtree=True?effective``.
Test Plan:
Call GET /role_assignments?scope.OS-INHERIT:inherited_to.
Test Plan:
Call GET /role_assignments.
Test Plan:
Get role_assignment?scope.project.id=X?include_subtree``.
Test Plan:
Call GET /role_assignments with inherited domain grants.
Test Plan:
Call GET /role_assignments with inherited domain grants.
Test Plan:
Call GET /role_assignments with inherited group domain grants.
Test Plan:
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.test_v3.AssignmentTestMixin
Test roles and role assignments.
Call GET /role_assignments?effective=value.
Check the various ways of specifying the ‘effective’ query parameter. If the ‘effective’ query parameter is included then this should always be treated as meaning ‘True’ unless it is specified as:
{url}?effective=0
This is by design to match the agreed way of handling policy checking on query/filter parameters.
Test Plan:
Grant role on a domain to a group that doesn’t exist.
When grant a role on a domain to a group that doesn’t exist, the server returns 404 Not Found for the group.
Grant role on a project to a group that doesn’t exist.
When grant a role on a project to a group that doesn’t exist, the server returns 404 Not Found for the group.
Grant role on a domain to a user that doesn’t exist.
When grant a role on a domain to a user that doesn’t exist, the server returns 404 Not Found for the user.
Grant role on a project to a user that doesn’t exist.
When grant a role on a project to a user that doesn’t exist, the server returns Not Found for the user.
Call DELETE on the user and check the role assignment.
Call DELETE on the user before the role assignment.
Call GET /role_assignments?filters.
Test Plan:
Call GET /role_assignments?effective.
Test Plan:
Call GET /role_assignments.
The sample data set up already has a user, group and project that is part of self.domain. We use these plus a new user we create as our data set, making sure we ignore any role assignments that are already in existence.
Since we don’t yet support a first class entity for role assignments, we are only testing the LIST API. To create and delete the role assignments we use the old grant APIs.
Test Plan:
Test token is revoked when group role grant is revoked
When a role granted to a group is revoked for a given scope, all tokens related to this scope and belonging to one of the members of this group should be revoked.
The revocation should be independently to the presence of the revoke API.
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.core.TestCase
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.test_v3.AssignmentTestMixin, keystone.tests.unit.core.TestCase
Call GET /role_assignments with implied role grant.
Test Plan:
Test root role is forbidden to be set as an implied role.
Create 2 roles that are prohibited from being an implied role. Create 1 additional role which should be accepted as an implied role. Assure the prohibited role names cannot be set as an implied role. Assure the accepted role name which is not a member of the prohibited implied role list can be successfully set an implied role.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Tests for /users/<user>/projects
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.test_v3.AssignmentTestMixin
Base class for testing /v3/role_assignments API behavior.
Returns the result from querying role assignment API + queried URL.
Calls GET /v3/role_assignments?<params> and returns its result, where <params> is the HTTP query parameters form of effective option plus filters, if provided. Queried URL is returned as well.
| Returns: | a tuple containing the list role assignments API response and queried URL. |
|---|
Bases: keystone.tests.unit.test_v3_assignment.RoleAssignmentBaseTestCase
Class for testing direct assignments on /v3/role_assignments API.
Direct assignments on a domain or project have effect on them directly, instead of on their project hierarchy, i.e they are non-inherited. In addition, group direct assignments are not expanded to group’s users.
Tests on this class make assertions on the representation and API filtering of direct assignments.
Bases: keystone.tests.unit.test_v3_assignment.RoleAssignmentInheritedTestCase
Class for testing inheritance effects on /v3/role_assignments API.
Inherited assignments on a domain or project have no effect on them directly, but on the projects under them instead.
Tests on this class make assertions on the effect of inherited assignments and API filtering.
Bases: keystone.tests.unit.test_v3_assignment.RoleAssignmentBaseTestCase
Class for testing invalid query params on /v3/role_assignments API.
Querying domain and project, or user and group results in a HTTP 400 Bad Request, since a role assignment must contain only a single pair of (actor, target). In addition, since filtering on role assignments applies only to the final result, effective mode cannot be combined with i) group or ii) domain and inherited, because it would always result in an empty list.
Bases: keystone.tests.unit.test_v3_assignment.RoleAssignmentDirectTestCase
Class for testing inherited assignments on /v3/role_assignments API.
Inherited assignments on a domain or project have no effect on them directly, but on the projects under them instead.
Tests on this class do not make assertions on the effect of inherited assignments, but in their representation and API filtering.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
On authenticate, get a catalog that excludes disabled endpoints.
On authenticate, get a catalog that excludes disabled services.
Verify getting a token in cross domain group/project roles.
Verify authenticate to a domain with unsafe name fails.
Verify authenticate to a project with unsafe name fails.
Verify authenticate to a project using unsafe domain name fails.
Test correct roles are returned in scoped token.
Test Plan:
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Bases: keystone.tests.common.auth.AuthTestMixin, testtools.testcase.TestCase
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Bases: keystone.tests.unit.test_v3_auth.TestAuthExternalDomain
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.test_v3_auth.TokenAPITests, keystone.tests.unit.test_v3_auth.TokenDataTests
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test fetch token revocation list on the v3 Identity API.
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.test_v3_auth.TokenAPITests, keystone.tests.unit.test_v3_auth.TokenDataTests
Bases: keystone.tests.unit.test_v3_auth.TestTokenRevokeById
Test token revocation on the v3 Identity API.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test token revocation on the v3 Identity API.
Setup for Token Revoking Test Cases.
As well as the usual housekeeping, create a set of domains, users, groups, roles and projects for the subsequent tests:
Test deleting a group grant revokes tokens.
Test Plan:
Test deleting a role revokes token.
Add some additional test data, namely:
Test deleting a user grant revokes token.
Test Plan:
Test domain-group role assignment maintains existing token.
Test Plan:
Test user-domain role assignment maintains existing token.
Test Plan:
Test add/removal to/from group revokes token.
Test Plan:
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test token revoke using v3 Identity API by token owner and admin.
Bases: keystone.tests.unit.test_v3_auth.TrustAPIBehavior, keystone.tests.unit.test_v3_auth.TestTrustChain
Bases: keystone.tests.unit.test_v3_auth.TrustAPIBehavior, keystone.tests.unit.test_v3_auth.TestTrustChain
Bases: keystone.tests.unit.test_v3_auth.TrustAPIBehavior, keystone.tests.unit.test_v3_auth.TestTrustChain
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.test_v3_auth.TokenAPITests, keystone.tests.unit.test_v3_auth.TokenDataTests
Bases: object
Test the data in specific token types.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Redelegation valid and secure
Redelegation is a hierarchical structure of trusts between initial trustor and a group of users allowed to impersonate trustor and act in his name. Hierarchy is created in a process of trusting already trusted permissions and organized as an adjacency list using ‘redelegated_trust_id’ field. Redelegation is valid if each subsequent trust in a chain passes ‘not more’ permissions than being redelegated.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test service & endpoint CRUD.
EndpointV3 allows to creates the endpoint without region.
EndpointV3 creates the region before creating the endpoint.
This occurs when endpoint is provided with ‘region’ and no ‘region_id’.
Call PUT /regions/{region_id} with conflicting region IDs.
Call POST /regions with an empty ID in the request body.
Call PUT /regions/{region_id} with an ID in the request body.
Call POST /regions without description in the request body.
Call POST /regions with duplicate descriptions.
Test the invalid cases: substitutions is not exactly right.
Create endpoint with valid url should be tested,too.
Call GET /endpoints?region_id={region_id}.
Ensure passing the parent_region_id as filter returns an empty list.
Call GET /endpoints?interface={interface}....
Ensure passing different combinations of interface, region_id and service_id as filters will return the correct result.
Call GET /endpoints?interface={interface}....
Ensure passing random values for: interface, region_id and service_id will return an empty list.
Call GET /regions?parent_region_id={parent_region_id}.
Call PATCH /endpoints/{endpoint_id} with enabled: False.
Call PATCH /endpoints/{endpoint_id} with enabled: ‘False’.
Call PATCH /endpoints/{endpoint_id} with enabled: ‘kitties’.
Call PATCH /endpoints/{endpoint_id} with enabled: ‘True’.
Bases: keystone.tests.unit.core.TestCase
Tests for the catalog Manager against the SQL backend.
Bases: keystone.tests.unit.core.TestCase
Tests for the catalog Manager against the SQL backend.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Templated Catalog doesn’t support full API.
Eg. No region/endpoint creation.
Deleting a project should not result in an 500 ISE.
The EndpointFilter extension of the Catalog API will create a notification when a project is deleted (attempting to clean up project->endpoint relationships). In the case of a templated catalog, no deletions (via catalog_api.delete_association_by_project) can be performed and result in a NotImplemented exception. We catch this exception and ignore it since it is expected.
Bases: keystone.tests.unit.test_v3_credential.CredentialBaseTestCase
Test credential CRUD.
Test creating ec2 credential with invalid blob.
Call POST /credentials.
Test Creating ec2 credential with missing project_id.
Call POST /credentials.
Bases: keystone.tests.unit.test_v3_credential.CredentialBaseTestCase
Test v3 credential compatibility with ec2tokens.
Test signature validation with a v3 ec2 credential.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test credential with trust scoped token.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test domain config support.
Call PUT /domains/{domain_id}/config
While creating Identity API-based domain config with an invalid domain id provided, the request shall be rejected with a response, 404 domain not found.
Call DELETE /domains{domain_id}/config/{group}
While deleting Identity API-based domain config by group with an invalid domain id provided, the request shall be rejected with a response 404 domain not found.
Call DELETE /domains{domain_id}/config
While deleting Identity API-based domain config with an invalid domain id provided, the request shall be rejected with a response, 404 domain not found.
Call GET & HEAD /domains{domain_id}/config/{group}
While retrieving Identity API-based domain config by group with an invalid domain id provided, the request shall be rejected with a response 404 domain not found.
Call GET & HEAD /domains{domain_id}/config/{group}/{option}
While retrieving Identity API-based domain config by option with an invalid domain id provided, the request shall be rejected with a response 404 domain not found.
Call GET for /domains/config/{bad-group}/default.
Call GET for /domains/config/{group}/{bad-option}/default.
Call GET /domains{domain_id}/config/{group_not_exist}.
Call GET /domains{domain_id}/config/{group_not_exist}
While retrieving non-existent Identity API-based domain config group with an invalid domain id provided, the request shall be rejected with a response, 404 domain not found.
Call GET /domains{domain_id}/config when no config defined
While retrieving non-existent Identity API-based domain config with an invalid domain id provided, the request shall be rejected with a response 404 domain not found.
Call GET /domains{domain_id}/config/group/{option_not_exist}.
Call GET /domains{domain_id}/config/group/{option_not_exist}
While retrieving non-existent Identity API-based domain config option with an invalid domain id provided, the request shall be rejected with a response, 404 domain not found.
Call PATCH /domains/{domain_id}/config/{group}
While updating Identity API-based domain config group with an invalid domain id provided, the request shall be rejected with a response, 404 domain not found.
Call PATCH /domains/{domain_id}/config
While updating Identity API-based domain config with an invalid domain id provided, the request shall be rejected with a response, 404 domain not found.
Call PATCH /domains/{domain_id}/config/{invalid_group}
While updating Identity API-based domain config with an invalid group and an invalid domain id provided, the request shall be rejected with a response, 404 domain not found.
Call PATCH /domains/{domain_id}/config/{group}/{invalid}.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test endpoint policy CRUD.
In general, the controller layer of the endpoint policy extension is really just marshalling the data around the underlying manager calls. Given that the manager layer is tested in depth by the backend tests, the tests we execute here concentrate on ensuring we are correctly passing and presenting the data.
PUT, HEAD and DELETE for explicit endpoint policy.
Bases: keystone.tests.unit.test_v3.JsonHomeTestMixin
Bases: keystone.tests.unit.test_v3.RestfulTestCase
A test class for Identity Providers.
Assign protocol to IdP that doesn’t exist.
Expect HTTP 404 Not Found code.
Add same IdP twice.
Expect HTTP 409 Conflict code for the latter call.
Creates two IdentityProvider entities with some remote_ids
A remote_id is the same for both so the second IdP is not created because of the uniqueness of the remote_ids
Expect HTTP 409 Conflict code for the latter call.
Create and later delete IdP.
Expect HTTP 404 Not Found for the GET IdP call.
Deleting an IdP will delete its assigned protocol.
Delete nonexisting IdP.
Expect HTTP 404 Not Found for the GET IdP call.
Delete protocol.
Expect HTTP 404 Not Found code for the GET call after the protocol is deleted.
Fetch nonexisting IdP entity.
Expected HTTP 404 Not Found status code.
Lists all available IdentityProviders.
This test collects ids of created IdPs and intersects it with the list of all available IdPs. List of all IdPs can be a superset of IdPs created in this test, because other tests also create IdPs.
Create set of protocols and later list them.
Compare input and output id sets.
Test that Keystone can add two entities.
The entities have identical names, however, attached to different IdPs.
Expect HTTP 201 code
Test whether Keystone checks for unique idp/protocol values.
Add same protocol twice, expect Keystone to reject a latter call and return HTTP 409 Conflict code.
Update IdP’s immutable parameters.
Expect HTTP BAD REQUEST.
Bases: object
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.test_v3_federation.FederatedSetupMixin
Test parameters filtering based on the prefix.
With assertion_prefix set to fixed, non default value, issue an unscoped token from assertion EMPLOYEE_ASSERTION_PREFIXED. Expect server to return unscoped token.
Test parameters filtering based on the prefix.
With assertion_prefix default value set to empty string issue an unscoped token from assertion EMPLOYEE_ASSERTION. Next, configure assertion_prefix to value UserName. Try issuing unscoped token with EMPLOYEE_ASSERTION. Expect server to raise exception.Unathorized exception.
Test a mapping with empty blacklist specified
Not adding a blacklist keyword to the mapping rules has the same effect as adding an empty blacklist. In both cases, the mapping engine will not discard any groups that are associated with apache environment variables.
This test checks scenario where an empty blacklist was specified. Expected result is to allow any value.
Test that empty whitelist blocks all the values
Not adding a whitelist keyword to the mapping value is different than adding empty whitelist. The former case will simply pass all the values, whereas the latter would discard all the values.
This test checks scenario where an empty whitelist was specified. The expected result is that no groups are matched.
Test ‘standard’ workflow for granting access tokens.
Inject assertion that matches rule issuing bad group id.
Expect server to find out that some groups are missing in the backend and raise exception.MappedGroupNotFound exception.
Checks if authentication works with disabled identity providers.
Test plan: 1) Disable default IdP 2) Try issuing unscoped token for that IdP 3) Expect server to forbid authentication
Test whether non string objects are filtered out.
Put non string objects into the environment, inject correct assertion and try to get an unscoped token. Expect server not to fail on using split() method on non string objects and return token id in the HTTP header.
Test that protocol remote_id_attribute has higher priority.
Make sure the parameter stored under protocol section has higher priority over parameter from default federation configuration section.
Test a mapping that points to a group that does not exist
For explicit mappings, we expect the group to exist in the backend, but for lists, specifically blacklists, a missing group is expected as many groups will be specified by the IdP that are not Keystone groups.
Test a mapping without blacklist specified.
Not adding a blacklist keyword to the mapping rules has the same effect as adding an empty blacklist. In both cases all values will be accepted and passed.
This test checks scenario where an blacklist was not specified. Expected result is to allow any value.
Test that not setting whitelist passes
Not adding a whitelist keyword to the mapping value is different than adding empty whitelist. The former case will simply pass all the values, whereas the latter would discard all the values.
This test checks a scenario where a whitelist was not specified. Expected result is that no groups are ignored.
Issue multiple tokens scoping to different domains.
The new tokens should be scoped to:
Try to scope to a domain that has no direct roles.
Try to scope the unscoped token multiple times.
The new tokens should be scoped to:
Try to scope token whose only roles are inherited.
Try to scope token from non-existent unscoped token.
Scope token issued by disabled IdP.
Try scoping the token issued by an IdP which is disabled now. Expect server to refuse scoping operation.
This test confirms correct behaviour when IdP was enabled and unscoped token was issued, but disabled before user tries to scope the token. Here we assume the unscoped token was already issued and start from the moment where IdP is being disabled and unscoped token is being used.
Test plan: 1) Disable IdP 2) Try scoping unscoped token
Test that using a federation token with v2 auth fails.
If an admin sets up a federated Keystone environment, and a user incorrectly configures a service (like Nova) to only use v2 auth, the returned message should be informative.
Test full workflow with groups deletion before token scoping.
Bases: keystone.tests.unit.test_v3_federation.FederatedTokenTests
Test federation operation with unified scoping auth method.
Test all the operations with auth method set to token as a new, unified way for scoping all the tokens.
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.test_v3_federation.FederatedSetupMixin
Tests for federated users
Tests new shadow users functionality
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.test_v3_federation.FederatedSetupMixin
Bases: keystone.tests.unit.test_v3.RestfulTestCase
A class for testing Identity Provider Metadata generation.
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.test_v3.JsonHomeTestMixin
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test service catalog with disabled service providers.
There should be no entry service_providers in the catalog. Test passes providing no attribute was raised.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
A class for testing CRUD operations for Mappings.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test that the ECP generation endpoint produces XML.
The ECP endpoint /v3/auth/OS-FEDERATION/saml2/ecp should take the same input as the SAML generation endpoint (scoped token ID + Service Provider ID). The controller should return a SAML assertion that is wrapped in a SOAP envelope.
Test that the SAML generation endpoint produces XML.
The SAML endpoint /v3/auth/OS-FEDERATION/saml2 should take as input, a scoped token ID, and a Service Provider ID. The controller should fetch details about the user from the token, and details about the service provider from its ID. This should be enough information to invoke the SAML generator and provide a valid SAML (XML) document back.
Test that missing the scope in request body raises an exception.
Raises exception.SchemaValidationError() - error 400 Bad Request
Test that missing the token in request body raises an exception.
Raises exception.SchemaValidationError() - error 400 Bad Request
Ensure SAML generation fails when passing domain-scoped tokens.
The server should return a 403 Forbidden Action.
Test that the SAML generator produces a SAML object.
Test the SAML generator directly by passing known arguments, the result should be a SAML object that consistently includes attributes based on the known arguments that were passed in.
Test the SAML generator produces a SAML object.
Test the SAML generator directly by passing known arguments, the result should be a SAML object that consistently includes attributes based on the known arguments that were passed in.
Test SAML generation with an invalid service provider ID.
Raises exception.ServiceProviderNotFound() - error Not Found 404
Test that an invalid token in the request body raises an exception.
Raises exception.TokenNotFound() - error Not Found 404
Bases: keystone.tests.unit.test_v3.RestfulTestCase
A test class for Service Providers.
Create an SP without relay state, should default to ss:mem.
Test listing of service provider objects.
Add two new service providers. List all available service providers. Expect to get list of three service providers (one created by setUp()) Test if attributes match.
Update existing service provider.
Update default existing service provider and make sure it has been properly changed.
Bases: keystone.tests.unit.test_v3_federation.FederatedTokenTests
A class for testing Web SSO.
Bases: keystone.tests.unit.filtering.FilterTests, keystone.tests.unit.test_v3.RestfulTestCase
Test filter enforcement on the v3 Identity API.
Create sample data for these tests.
As well as the usual housekeeping, create a set of domains, users, roles and projects for the subsequent tests:
Remember that there will also be a fourth domain in existence, the default domain.
GET /users?name=<injected sql_statement>
Test Plan:
GET /domains?enableds&name=myname
Test Plan:
GET /domains?enabled=0
Test Plan:
GET /users?domain_id=mydomain (filtered)
Test Plan:
Bases: keystone.tests.unit.test_v3_filters.IdentityTestFilteredCase
Test list limiting enforcement on the v3 Identity API.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test users and groups.
Call POST /users with admin token and domain id.
Call POST /users without specifying domain.
According to the identity-api specification, if you do not explicitly specific the domain_id in the entity, it should take the domain scope of the token as the domain_id.
Call DELETE /users/{user_id}.
As well as making sure the delete succeeds, we ensure that any credentials that reference this user are also deleted, while other credentials are unaffected. In addition, no tokens should remain valid for this user.
Call GET /users/{user_id} making sure of default_project_id.
Call GET /users when multiple backends is enabled.
In this scenario, the controller requires a domain to be specified either as a filter or by using a domain scoped token.
Illustrate the inconsistent handling of hyphens in keys.
To quote Morgan in bug 1526244:
the reason this is converted from “domain-id” to “domain_id” is because of how we process/normalize data. The way we have to handle specific data types for known columns requires avoiding “-” in the actual python code since “-” is not valid for attributes in python w/o significant use of “getattr” etc.
In short, historically we handle some things in conversions. The use of “extras” has long been a poor design choice that leads to odd/strange inconsistent behaviors because of other choices made in handling data from within the body. (In many cases we convert from “-” to “_” throughout openstack)
Source: https://bugs.launchpad.net/keystone/+bug/1526244/comments/9
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Bases: keystone.tests.unit.core.TestCase
Test users V3 to V2 conversion methods.
Bases: keystone.tests.unit.test_v3_oauth1.OAuthFlowTests
Bases: keystone.tests.unit.test_v3_oauth1.OAuth1Tests, keystone.tests.unit.test_v3.JsonHomeTestMixin
Bases: keystone.tests.unit.test_v3_oauth1.OAuth1Tests
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Bases: keystone.tests.unit.test_v3_oauth1.OAuthNotificationTests
Bases: keystone.tests.unit.test_v3_oauth1.OAuth1Tests, keystone.tests.unit.common.test_notifications.BaseNotificationTest
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.test_v3.JsonHomeTestMixin
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test policy CRUD.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test policy enforcement of the policy.json file.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test policy enforcement on the v3 Identity API.
Setup for Identity Protection Test Cases.
As well as the usual housekeeping, create a set of domains, users, roles and projects for the subsequent tests:
Remember that there will also be a fourth domain in existence, the default domain.
GET /users/{id} (match payload)
Test Plan:
GET /users/{id} (match target)
Test Plan:
GET /groups?domain_id=mydomain (protected)
Test Plan:
GET /groups?domain_id=mydomain&name=myname (protected)
Test Plan:
GET /users?domain_id=mydomain (filtered)
Test Plan:
GET /users?domain_id=mydomain (protected)
Test Plan:
GET /users (unprotected)
Test Plan:
DELETE /domains/{id}/users/{id}/roles/{id} (match target)
Test Plan:
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.test_v3.AssignmentTestMixin
Test policy enforcement of the sample v3 cloud policy file.
Setup for v3 Cloud Policy Sample Test Cases.
The following data is created:
We test various api protection rules from the cloud sample policy file to make sure the sample is valid and that we correctly enforce it.
Tests getting and deleting ec2 credentials through the ec2 API.
Illustrate the inconsistent handling of hyphens in keys.
To quote Morgan in bug 1526244:
the reason this is converted from “domain-id” to “domain_id” is because of how we process/normalize data. The way we have to handle specific data types for known columns requires avoiding “-” in the actual python code since “-” is not valid for attributes in python w/o significant use of “getattr” etc.
In short, historically we handle some things in conversions. The use of “extras” has long been a poor design choice that leads to odd/strange inconsistent behaviors because of other choices made in handling data from within the body. (In many cases we convert from “-” to “_” throughout openstack)
Source: https://bugs.launchpad.net/keystone/+bug/1526244/comments/9
Bases: keystone.tests.unit.test_v3.RestfulTestCase, keystone.tests.unit.test_v3.AssignmentTestMixin
Test domains and projects.
Call POST /domains` twice with upper() and lower() cased name.
Check a project that acts as a domain is created.
Call POST /domains.
Call POST /projects is_domain and check a domain is created.
Call DELETE /domains/{domain_id}.
The sample data set up already has a user and project that is part of self.domain. Additionally we will create a group and a credential within it. Since the user we will authenticate with is in this domain, we create a another set of entities in a second domain. Deleting this second domain should delete all these new entities. In addition, all the entities in the regular self.domain should be unaffected by the delete.
Test Plan:
Check the project that acts as a domain is deleted.
Call DELETE /domains.
Call DELETE /projects/{project_id}
As well as making sure the delete succeeds, we ensure that any credentials that reference this projects are also deleted, while other credentials are unaffected.
Make sure one cannot operate on a user-defined federated domain.
This includes operations like create, update, delete.
Make sure one cannot operate on federated domain.
This includes operations like create, update, delete on domain identified by id and name where difference variations of id ‘Federated’ are used.
Attempt to list a project’s parents as both a list and as IDs.
This uses GET /projects/{project_id}?parents_as_list&parents_as_ids which should fail with a Bad Request due to the conflicting query strings.
GET /projects/{project_id}?parents_as_list with full access.
Test plan:
Call GET /projects/{project_id}?parents_as_list.
GET /projects/{project_id}?parents_as_list with partial access.
Test plan:
Call GET /projects/{project_id}?subtree_as_ids.
This test creates a more complex hierarchy to test if the structured dictionary returned by using the subtree_as_ids query param correctly represents the hierarchy.
The hierarchy contains 5 projects with the following structure:
+--A--+
| |
+--B--+ C
| |
D E
Attempt to get a project subtree as both a list and as IDs.
This uses GET /projects/{project_id}?subtree_as_list&subtree_as_ids which should fail with a bad request due to the conflicting query strings.
GET /projects/{project_id}?subtree_as_list with full access.
Test plan:
Call GET /projects/{project_id}?subtree_as_list.
GET /projects/{project_id}?subtree_as_list with partial access.
Test plan:
Default project list should not see projects acting as domains
Test token from a disabled domain has been invalidated.
Test that a token that was valid for an enabled domain becomes invalid once that domain is disabled.
Check the project that acts as a domain is updated.
Call PATCH /domains.
Bases: keystone.tests.unit.core.TestCase
Test domain V3 to V2 conversion methods.
Bases: keystone.tests.unit.test_v3.RestfulTestCase
Test module for create, read, update and delete operations on trusts.
This module is specific to tests for trust CRUD operations. All other tests related to trusts that are authentication or authorization specific should live in in the keystone/tests/unit/test_v3_auth.py module.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Credential API validation.
Validate project_id is required for ec2.
Test that a SchemaValidationError is raised when type is ec2 and no project_id is provided in create request.
Validate project_id is not required for non-ec2.
Test that create request without project_id succeeds for any non-ec2 credential.
Test that a credential request is properly validated.
Validate credential update with extra parameters.
Exception is raised on update without parameters.
Validate create request with extra parameters.
Test that credential request works for all types.
Exception raised without blob in create request.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Domain API validation.
Validate enabled as boolean-like values for domains.
Exception is raised when description is a non-string value.
Exception is raised when enabled isn’t a boolean-like value.
Exception is raised when name is too long.
Exception raised when name is too short.
Test that we validate description in create domain requests.
Make sure we raise an exception when name isn’t included.
Exception raised when updating a domain with name too long.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Endpoint Group API validation.
Validate invalid filters value in endpoint group parameters.
This test ensures that exception is raised when non-dict values is used as filters in endpoint group create request.
Exception raised when filters isn’t in endpoint group request.
Exception raised when name isn’t in endpoint group request.
Validate required endpoint group parameters.
This test ensure that validation succeeds with only the required parameters passed for creating an endpoint group.
Validate filters in endpoint group create requests.
Test that we validate an endpoint group request.
Exception raised when passing invalid filters in request.
Exception raised when no parameters on endpoint group update.
Test that we validate an endpoint group update request.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Endpoint API validation.
Exception raised when boolean-like values as enabled.
Exception raised with invalid interface.
Exception raised when passing invalid region(_id) in request.
Exception raised when passing invalid url in request.
Exception raised when interface isn’t in endpoint request.
Exception raised when service_id isn’t in endpoint request.
Exception raised when url isn’t in endpoint request.
Test that extra parameters pass validation on create endpoint.
Validate an endpoint request with only the required parameters.
Validate url attribute in endpoint create request.
Validate an endpoint with boolean values.
Validate boolean values as enabled in endpoint create requests.
Exception raised when enabled is boolean-like value.
Exception raised when invalid interface on endpoint update.
Exception raised when passing invalid region(_id) in request.
Exception raised when passing invalid url in request.
Exception raised when no parameters on endpoint update.
Test that we validate an endpoint update request.
Test that extra parameters pass validation on update endpoint.
Bases: keystone.tests.unit.core.BaseTestCase
Validate all parameter values against test schema.
Validate invalid email address.
Test that an exception is raised when validating improperly formatted email addresses.
Validate invalid enabled formats.
Test that an exception is raised when passing invalid boolean-like values as enabled.
Exception raised when using invalid id strings.
Test that an exception is raised when validating improper urls.
Validate long names.
Validate that an exception is raised when validating a string of 255+ characters passed in as a name.
Validate short names.
Test that an exception is raised when passing a string of length zero as a name parameter.
Validate that None is an acceptable optional string type.
Exception raised when passing None on required id strings.
Validate correct for only parameters values against test schema.
Test that we successfully validate a unicode string.
Validate email address
Test that we successfully validate properly formatted email addresses.
Validate valid enabled formats.
Test that we have successful validation on boolean values for enabled.
Test that proper urls are successfully validated.
Optional parameters can be null to removed the value.
The name parameter can’t be null.
Succeeds with only a single valid optional parameter.
Succeed if a valid required parameter is provided.
Simulate updating an entity by ID.
Fails when an optional parameter is invalid.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Federation Protocol API validation.
Exception raised when mapping_id is not string.
Exception raised when unknown parameter is found.
Test that schema validation with empty request body.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Group API validation.
Exception raised when group name is equal to zero.
Exception raised when group name is not provided in request.
Validate create group requests with all parameters.
Validate extra attributes on group create requests.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Identity Provider API validation.
Exception raised when unknown parameter is found.
Test that schema validation with empty request body.
Test that remote_ids could be explicitly set to None
Exception is raised when the duplicated remote_ids is found.
Exception is raised when description as a non-string value.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Identity OAuth1 API validation.
Test that we validate a consumer request successfully.
Exception is raised when description as a non-string value.
Test that schema validation with empty request body.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Policy API validation.
Validate policy create with extra parameters.
Exception raised when blob and type are boolean.
Validate policy update request with extra parameters.
Exception raised when invalid type on policy update.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Project API validation.
Test that we validate domain_id in create project requests.
Validate enabled as boolean-like values for projects.
Exception is raised when description as a non-string value.
Exception is raised when domain_id is a non-id value.
Exception is raised when enabled isn’t a boolean-like value.
Exception is raised when parent_id as a non-id value.
Exception is raised when name is too long.
Exception raised when name is too short.
Test that we validate description in create project requests.
Test that we validate parent_id in create project requests.
Validate project request fails without name.
Exception raised when updating a project with name too long.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Region API validation.
Exception raised when passing invalid id in request.
Test that we validate a region request with parameters.
Validate create region request with extra values.
Validate create region request with no parameters.
Test that we validate a region request with a UUID as the id.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Role API validation.
Exception is raised on role create with a non-string name.
Test that we raise an exception when name isn’t included.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Service Provider API validation.
Exception raised when passing extra fields in the body.
Validate request fails with invalid auth_url.
Exception is raised when description as a non-string value.
Exception is raised when enabled isn’t a boolean-like value.
Validate request fails with invalid sp_url.
Test that we validate description in create requests.
Exception raised when updating with invalid auth_url.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Service API validation.
Exception raised when name is greater than 255 characters.
Exception is raised when name is too short.
Exception is raised when type is too long.
Exception is raised when type is too short.
Exception raised when boolean-like parameters as enabled
On service create, make sure an exception is raised if enabled is not a boolean value.
Exception raised when trying to create a service without type.
Test that extra parameters pass validation on create service.
Validate a service create request with the required parameters.
Validate boolean values as enabled values on service create.
Exception raised when boolean-like values as enabled.
Exception is raised when name is too long on update.
Exception is raised when name is too short on update.
Exception raised when updating a service without values.
Exception is raised when type is too long on update.
Exception is raised when type is too short on update.
Test that we validate a service update request.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 Trust API validation.
Test that we can validate a trust request with all parameters.
Test that we can validate a trust request with extra parameters.
Validate trust request with invalid expires_at fails.
Validate trust request with invalid impersonation fails.
Validate trust request with invalid roles fails.
Validate trust request with a list of valid roles.
Validate trust request with null remaining_uses.
Validate trust request with a period in the user id string.
Validate trust request with remaining_uses succeeds.
Validate trust request fails without impersonation.
Bases: keystone.tests.unit.core.BaseTestCase
Test for V3 User API validation.
Exception raised when enabled is not an acceptable format.
Exception raised when user password is of the wrong type.
Exception raised when validating a username of wrong type.
Exception raised when validating a username with length of zero.
Exception raised when validating a user without name.
Test that validating a user create request succeeds.
Validate extra parameters on user create requests.
Validate that description can be nullable on create user.
Validate that password is nullable on create user.
Validate empty password on user create requests.
Validate acceptable enabled formats in create user requests.
Test that validating a user create request succeeds.
Bases: keystone.tests.unit.core.BaseTestCase
Used to test cases where there is an optional body.
Test the case when client passing in an empty entity reference.
Test the case when client passing in an empty kwarg reference.
Test the case when client passing in an empty entity reference.
Used to test cases where validated param is not the only param.
Bases: keystone.tests.unit.core.TestCase
Tests running with a single application loaded.
These are important because when Keystone is running in Apache httpd there’s only one application loaded for each instance.
Useful utilities for tests.
Mark a test as work in progress.
Based on code by Nat Pryce: https://gist.github.com/npryce/997195#file-wip-py
The test will always be run. If the test fails then a TestSkipped exception is raised. If the test passes an AssertionError exception is raised so that the developer knows they made the test pass. This is a reminder to remove the decorator.
| Parameters: | message – a string message to help clarify why the test is marked as a work in progress |
|---|
>>> @wip('waiting on bug #000000')
>>> def test():
>>> pass