Created by: Jonas1893
Summary
This adds the ability to easily distinguish between endpoints that should be requested authenticated and those that should be requested unauthenticated.
Motivation
Currently the intended way of authentication according to the FAQs is to implement a custom RequestBuilder overriding execute (URLSession) or to inject a custom RequestInterceptor (AF library). The drawback here is that the information from the swagger spec (via the security scheme annotation), whether an endpoint needs to be requested authenticated or not is not available anymore at this level in the code. There were discussion on how to handle this properly but without definite outcome. Currently, it is necessary to maintain a whitelist of requests that need to be requested (un-)authenticated in the app logic.
Changes in this PR
This PR adds a new property to RequestBuilder to distinguish (un-)authenticated requests. It is now possible to decide in RequestBuilder logic how to handle authentication (like e.g. adapting request with a token or not)
Other effects
- The FAQs and linked sample codes would need to be adopted as well
PR checklist
-
Read the contribution guidelines. -
Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community. -
Run the following to build the project and update samples: Commit all changed files. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example./mvnw clean package ./bin/generate-samples.sh ./bin/utils/export_docs_generators.sh./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH. -
File the PR against the correct branch: master(6.1.0) (minor release - breaking changes with fallbacks),7.0.x(breaking changes without fallbacks) -
If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. -> @4brunu this is the alternative approach we discussed in #13318
Declaration
The program was tested solely for our own use cases, which might differ from yours.