When the keystonemiddleware is used directly in the WSGI stack of an
application, the 503 that is raised when the keystone service errors
or cannot be reached needs to identify that keystone is the service
that has failed, otherwise it appears to the client that it is the
service they are trying to access is down, which is misleading.
This addresses the problem in the most straightforward way possible:
the exception that causes the 503 is given a message including the
word "Keystone".
The call method in BaseAuthTokenTestCase gains an
expected_body_string kwarg. If not None, the response body (as
a six.text_type) is compared with the value.
Change-Id: Idf211e7bc99139744af232f5ea3ecb4be41551ca
Closes-Bug: #1747655
Closes-Bug: #1749797
The constants of log levels were added in the 1.8 version
of the oslo.log library.
So we can replace all usage of system logging module
with log module from oslo.log
Change-Id: I97a1d913b543dc9dbd4d228b04adbdf7ee320df5
The auth_token tests have a good layout for using create_middleware and
create_simple_middleware that makes it easy for tests to create
middleware for testing as required rather than having a self.middleware
object that gets overriden a lot.
Extract this create_middleware into a base class and implement it in
audit so the patterns are similar.
Change-Id: I2f050eef1684c8046f94dc2b88b4c97a56ea9cd8
Calling a ConfigOpts instance with new args will implicitly reset
the config values in the instance. This means that in the previous
revision of the code, any assignment of oslo_config_config to
self._local_oslo_config would be instantly clobbered by calling
self._local_oslo_config() to read from default_config_files.
Now, if oslo_config_config is set to a non-None value it will be
left unmolested. This is useful because oslo_config_config turns out
to be the ideal way to pass config to AuthProtocol when the caller
already has access to the project config object and neither global
conf nor paste is being used.
Change-Id: I0beb809bc5ace609561f10dc52800a8a6e03f7e6
Closes-Bug: #1540022
Check expected response status in the BaseAuthTokenTestCase.call() method
rather than in the test code.
Change-Id: Id0d5ffce84b1aea307d03b425bee1ec0838269c0
The auth_token tests were failing randomly (depending on which tests
were run together) because the global config had options left in it
by other tests (options were added as part of auth plugin
initialization and oslo.config provides no way to remove registered
options).
This change makes it so that auth_token gets a fresh config for
every test (other than one test that requires using the global CONF
object).
Closes-Bug: 1494327
Change-Id: I647f7fade01e2a619f4a5d12a4e71897423469c1
A common base class is defined to provide a place to put fixtures
that affect all tests. For example, we could add a fixture that
ensures that no deprecated function was used.
Change-Id: I93aa45fa8284d8cdd8b0f71f137a261610e31988
One of the reasons that there are so many unrelated tests in the basic
test_auth_token_middleware tests file is that there is a lot of token
and mocking setup that is required for all tests.
Firstly extract a base class with some middleware creation helpers. Use
these in the existing tests. Remove the concept of start_request. webob
has helpers that can simplify this into the standard request/response
handling so there is no reason we need this and we don't want to copy it
to new test files.
Change-Id: I31bb40feb1915b75193eac621be5501dde162f08
Stephen Finucane