codecov[bot]
commented
9 months ago Codecov Report
Attention: 5 lines in your changes are missing coverage. Please review.
Comparison is base (
474caaf) 20.74% compared to head (9b6c8ed) 20.73%. Report is 25 commits behind head on develop.
Brief description of the PR If you tried to call the API using a wrong auth token (for example, empty or expired) Kapua was returning a wrong error message in the HTTP body regarding the CORS filtering error, even though the "allowed origins" contained the origin used to perform the call. The right response you would expect in this case is a 401 error code and nothing else.
Description of the solution adopted This problem was caused by a regression I introduced in a past work on the CORS filtering logic. I didn't realize that the KapuaTokenAuthenticationFilter class, upon wrong authentication, was continuing the filtering chain to the CORS filter, and this one had to perform the filtering before returning the 401 error code to the client. This is the reason behind (see also https://github.com/eclipse/kapua/pull/3324): the browser, having made an API request, will check first of all if the header of the response contains the origin headers. If not, it will display a network problem/CORS problem without showing the content of the response, even when it could contain, for example, a 401 status in the header. This means that to correctly display the 401 error code on the client side, the back-end side has to perform the cors filtering even if authentication fails.
Tests done to verify the change To test the change, I've performed API calls with swagger using both same-origin and cross-origin as values in the SEC_FETCH_SITE field of the header. Also, I tried using wrong, empty or expired token as auth. fields. In this way, all possible scenarios were covered