Skip to content
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

Add authentication credentials to request headers when client is launed #72

Open
MBueschelberger opened this issue Oct 13, 2022 · 2 comments · May be fixed by #75
Open

Add authentication credentials to request headers when client is launed #72

MBueschelberger opened this issue Oct 13, 2022 · 2 comments · May be fixed by #75
Assignees

Comments

@MBueschelberger
Copy link
Contributor

Related to the optional authentication layer in this PR of the oteapi-services, it would be benfitical that a user authenticates while the client is launed.

This could directly make use of the fastapi.security-package so that the token/credentials are automatically added to the request headers when the get-method of a stragety is called in a pipeline.

Suggestions for implementations will follow up soon.

@CasperWA CasperWA self-assigned this Oct 17, 2022
@CasperWA CasperWA linked a pull request Oct 17, 2022 that will close this issue
8 tasks
@CasperWA
Copy link
Contributor

CasperWA commented Sep 22, 2023

Could this not be done with the config pathway of setting headers in an OTE Service client as of now? Or are you thinking of something more specialized/pre-configured options?

For the config pathway, I mean something like:

from otelib import OTEClient

auth_client = OTEClient("https://api.ote-service.app", headers={"Authorization": "Bearer <token>"})

Where the actual token can then be loaded from a .env file or from a set environment variable or whatever?

Hmm, but if the key is to do login, etc, then the whole workflows should be different.

@MBueschelberger
Copy link
Contributor Author

Yes, sourcing the token from an .env file might be a much smarter and secure way than hardcoding it into a the script where you execute the pipeline.

However, this also might be limited if you would like to manage different access control parameters over different strategies. E.g. DataResourceConfig A takes token No 1 and TransformationConfig B takes token No 2.

If you do not specify it in the config while creating the strategies, the ote-services will by default take the token from the headers of the incoming request. This might become problematic in that way, that the wrong token might be passed to the wrong strategy when executing the pipeline.

Hence, if we would like to manage this more dynamically in a pydantic-setting, I think it makes sense to have to opportunity to manage all secrets this settings-object and map them there to all the strategies we would like to pass them later on.

But this is definitely a larger effort to implement this and I don't know in how far the otelib is intended to solve this procedure.

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

Successfully merging a pull request may close this issue.

2 participants