On Python 3, comparison between string (str) and integer (int) raises
a TypeError exception. I suggest to catch it to raise an InvalidInput
exception, as we already do for ValueError.
In practice, the TypeError was seen in OpenStack Cue tests on
Python 3, in a test passing a string to an attribute expecting an
integer, attribute having a minimum set (to an integer too).
Change-Id: I74103330ccb5cdc26aa3508fcefcc34310e00c27
Fix the failed test case
Traceback (most recent call last):
File "/opt/stack/wsme/wsme/tests/test_utils.py", line 78, in
test_parse_isodatetime
self.assertRaises(ValueError, utils.parse_isodatetime, s)
AssertionError: ValueError not raised
Change-Id: I6c36f8b0340cd7b4c6f35e7c7c5886598e2c5f0c
Closes-Bug: #1532734
* Use byte strings for HTTP body
* Remove debug print()
* tox.ini: add cornice-py3 test environment
Note: It looks like it doesn't work to inherit commands from cornice
into cornice-py3 because cornice commands use the substitution string
{posargs}.
Change-Id: Iaed39babc7ee9877d443c47c2f4b21b2e98b5181
When we parse the json object that come in query string,
we expect to find a dict, but not bail out if that not the case.
So this will raise a 500.
This changes this and return 400, because the input is invalid.
Change-Id: I1a3b927cdfb3b554026306d65a46ed91635d073c
Closes-bug: #1423634
When the body of a POST request cannot be decoded because
the content-type is not supported by any rest controller.
The server should return 415, not 500.
Related bug: #1419110
Change-Id: I8f8df4ab4062181e8d511e437a8486182c262ff8
If the expected datatype is ArrayType or DictType
but the json value is something else raise
ValueError instead of 500 erro because we can browse the
dict or the list.
Closes bug: #1428628
Change-Id: Ibd4d95815c0b81ded8304bba4ca83e6df32d86ae
If the object type is ArrayType or DictType, the datatype
is an object not a class. Currently a 500 error is raise
just because the exception path for invalid input handle only
when the datatype is an UserType or Class, not object.
This change fixes that.
Change-Id: Ifadef698a4dca0d33167bd4d5a567c43fe015108
Closes-bug: #1428185
Update the README file to list links in a format expected by the
OpenStack release tools so we can generate release announcement emails
automatically.
Change-Id: I84865bc1787ad980c65e49f7b6ae40c66d92b4e7
Set up the venv environment to let us use it for pre-release cross
testing to ensure we don't break consuming project unit tests.
Change-Id: If2bee203cb120b6c3b17a863fca2ece12651024f
Add an example in the documentation to show how to configure pyramid to
use the WSME extensions with cornice.
Closes-Bug: #1316888
Change-Id: Id1ad7149260205809de0b7f8ded51d45a8390880
Ipaddr module was never introduced by openstack and never used by
other openstack components. We should move to more reliable module
netaddr to validate ip format.
Change-Id: I38d0c6f4ea2147ce071ab62a7c9d546436aec185
Closes-Bug: #1455404
pytz was used in https://review.openstack.org/#/c/161013 but is not a WSME
dependency. This causes pecan test, which gates against WSME, to fail.
Change-Id: I71e60648a08f019c0da355ba2d25ea05d6fcdf2f
Fix the documentation where it sais that wsme.signature takes a status
argument: the actual name of the argument is status_code.
Closes-Bug: #1455563
Change-Id: Ifa3abef5654e5b796285a467fe5e6bce248ef60c
Check if a request is passing more attributes for complex objects than
those defined in the API. WSME did not care if some unknown attribute
was passed to an API with a complex type, only checking the required
attributes. This is fixed raising a ValueError if more attributes are
given than expected, resulting in an HTTP response with a 400 status.
This helps check the validity of requests, which would otherwise
unexpectedly work with (partially) invalid data.
Closes-Bug: #1277571
Change-Id: Idf720a1c3fac8bdc8dca21a1ccdb126110dae62e
Unit tests were still using the deprecated assertEquals instead of
assertEqual. This removes all mentions of assertEquals to use the new name and
be compatible with the OpenStack Style Guidelines.
Closes-Bug: #1454766
Partial-Bug: #1446692
Change-Id: Ieb90a334a0d0e91845d20a3e4ea4697307ed3f2a
Add some tests to verify that UserType objects are correctly converted
to the specified basetype. Bug #1228040 was based on a wrong usage of
the UserType base class, so these also stand as a further example of
correct usage.
Related-Bug: #1228040
Change-Id: I7d50164930c2ae7abeddcade4f876eef5b273b6b
If on a service exposed with some arguments with a built-in type among
int, long, bool or float a request is made passing a JSON with string
values instead of the intended type, the called function would have
strings as parameters instead of the expected types. This also means
that invalid strings would still be passed without error, leading to
unexpected failures. This patch tries to convert the string to the
intended type before failing with an InvalidInput exception if the
string can't be converted. This is to try and be as nice as possible
with whatever input is thrown at wsme.
Closes-Bug: 1450544
Change-Id: I705c183bb68457d539074b78ce81339b9464e1e0
The gate 34 tests were not running any tests because there was no
tox target. This changes tox-tmpl.ini (and the resulting tox.ini) to
add support for python 34 and remove support for anything that is
not py34 or py27-based.
To make the python3 tox environments work, the remote zip of a suds
fork has been replaced with suds-jurko, a relatively modern fork of
the original suds that supports python2 and 3.
Some tests needed to be fixed to deal with two main problems:
* reponse bodies being bytes
* Exceptions not having a .message attribute (.args[0] is used
instead)
* the test_flask tests were not being run for python3, they are now
* wsmeext/sphinxext.py intermittently fails due to the dictionary
changing size in flight, getting the keys prior to iteration fixes
it
Both 27 and 34 should be running 420 tests as of this commit.
Change-Id: I837c249714fd957790ea84aa2fd9ad994a39c5ea
The changes in 8710dabb652dae775dee31789e91608f832e62e6 broke
protocol failover when the REST protocol is listed before others
(see bug referenced below).
This patch tries to solve both issues by trying to match accept over all
the protocols, only giving up a 406 or 415 if all protocols fail, using
the last failure as the error message.
Related-Bug: #1419110
Closes-Bug: #1442710
Change-Id: I328a392151013c46207519c245213d5dec48ecc9
When you parse JSON, if some parts of the message have the wrong type of data
you would get a ValueError, returning a 500 HTTP status code. Now the
ValueError gets wrapped in an InvalidInput which will result in a 400 HTTP
response sent back to the client.
Closes-Bug: #1392409
Change-Id: I7702b824a98185d194a29d593b23e47dfd9bca3e
Instead of returning a 500 HTTP status code, return a 400 status code when the
received input is invalid JSON.
Also add a unit test for this case.
Closes-Bug: #1428462
Change-Id: Id02de0a7b8fcbcb07f7ac534519dcdc1cbb04839
Previously setup.py had information about which versions of libraries to depend
on based on the python version. Since we don't need to support those versions
anymore (2.5, 2.6 and 3.3), these dependancies can be listed in a
requirements.txt file. This can be set up to sync with global-requirements at
a later date.
ipaddr is added to requirements-py2.txt, since it is only needed on python
version lower than 3.3.
Change-Id: I90c4cbd7961ffdf6769578986c272bf9f5721d77
This patch is also adding the missing tests to the format_exception()
function since it's related to the fix.
Change-Id: Id1ab32076e5d112493216dcd92f80fe6e0199237
Closes-Bug: #1437125
Some print calls were polluting the standard output with debugging
information. These prints are now converted to logging.debug calls
so that they are disabled by default.
Closes-Bug: #1426439
Change-Id: I42f3ca62b55a980839cc0cb481f33fea3cd22afe
A client-side error (that is something akin to a 4xx HTTP response
code) is something that is common, it is not something that should
cause WARNING level log messages. This change switches to using
DEBUG so that it is easier to filter out the noisy messages.
Change-Id: I0ce0c7afa883612fd8a184b4244991f1e2a0e19d
This patch is extending the Response object and the Pecan extension
to make it possible to return a non-default return type (just like it
already supports retuning a non default status code).
This is useful when the return code of a function is 204 (No Response) for
that case we automatically set the return_type to be None and guarantee
that the response body is empty and the content-lentgh is 0. Which if
not done can cause tools consuming the API to misbehave.
Change-Id: I629c3e2d5dc169154e5af044f1b8f804e4b87e23
It currently returns an error with the text "Unknow mimetype." This
changes that to be "Unknown mimetype". Also fixes PEP8 reported by
the gate.
Change-Id: I7ac44f9cba713ddb352aab2a5698598a4da4f612
Originally, if WSME received an Accept or Content-Type header that
was not aligned with what it was prepared to handle it would error
out with a 500 status code. This is not good behavior for a web
service.
In the process of trying to fix this it was discovered that the
content-negotiation code within WSME (the code that, in part,
looks for a suitable protocol handler for a request) and tests of
that code are incorrect, violating expected HTTP behaviors. GET
requests are passing Content-Type headers to declare the desired
type of representation in the response. This is what Accept is for.
Unfortunately the server-side code was perfectly willing to accept
this behavior. These changes correct that.
Closes-Bug: 1419110
Change-Id: I2b5c0075611490c047b27b1b43b0505fc5534b3b
If there are side effects associated with the location of these
imports, the tests don't cover it, so we can only hope.
Change-Id: I86e9754ff96ed881515fb0c8f9997acff740471d
