Skip to content

securitySchemes: not supported #420

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
drahnr opened this issue Apr 15, 2023 · 5 comments
Open

securitySchemes: not supported #420

drahnr opened this issue Apr 15, 2023 · 5 comments

Comments

@drahnr
Copy link
Contributor

drahnr commented Apr 15, 2023

Currently when an openapi 3.0.0 spec contains a securitySchemes: and security attribute, it's not generating the appropriate code. It appears to be ignored entirely.

@drahnr
Copy link
Contributor Author

drahnr commented Apr 15, 2023

I have proof of concept that works with header based API keys

@ahl
Copy link
Collaborator

ahl commented Apr 19, 2023

Cool; can I see it?

@drahnr
Copy link
Contributor Author

drahnr commented May 10, 2023

I wish I could, I'll re-create it soon™ - the btrfs volume it resided on got deleted during a system-upgrade for whatever reason and that branch wasn't backed up 😶‍🌫️

@drahnr
Copy link
Contributor Author

drahnr commented May 10, 2023

@ahl see commit 0d3ccbf in #466 - I have to cleanup the mess at some point, it contains all the changes I needed for now and parts are not ready for inclusion

@tormeh
Copy link

tormeh commented Jan 17, 2024

For anyone who finds this: A possible workaround would be to make a new reqwest client for every request, add the authorization header as a default header, then make a new progenitor client based on that reqwest client using Client::new_with_client(url, reqwest_client).

(also bump)

@KamWithK KamWithK mentioned this issue Dec 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants