search

jdiazcano / cfg4k

Flexible and easy to use config library written in kotlin
Apache License 2.0
80 stars 6 forks source link

Authentication for URLConfigSource #45

Closed detouched closed 6 years ago

detouched commented 6 years ago

Current URLConfigSource lacks authentication, so the URL can only be public to be consumed by cfg4k (unless you tweak the global java.net.Authenticator which seems not the best way).

This change makes URLConfigSource to accept an optional generic content for Authorization header to be used when fetching the config from the provided URL. A helper function for encoding basic auth credentials is provided along the way just because it's easy on one hand but not completely trivial on the other.

detouched commented 6 years ago

I was thinking to make this argument more of a type (interface + implementations maybe), but since the general idea is to keep it all simple, I decided to leave it as a String. Let me know what you think about it.

detouched commented 6 years ago

Not directly related: I ran into a need to authenticate requests when I wanted to fetch my config from a file in a hosted repository but didn't want to use GitConfigSource to not to pull in JGit and keep less moving parts in general. In my case the config is hosted in a file of a repository on Bitbucket, but it could be on GitHub as well.

Here comes the question: do you think it's worth adding a handy ConfigSource implementations specifically for fetching config from Bitbucket/GitHub/... repositories? What these classes would do is essentially build a correct URL to a file and provide related authentication methods, e.g. GitHub has personal API tokens along with basic auth. These classes could live in a separate module(s) or in core...

jdiazcano commented 6 years ago

It will end up being a string in the header so for now I think it will be OK. The only thing that could worry me is the authorization header name but as far as I know is pretty standard.

This can be changed in the future so I wouldn't worry too much

jdiazcano commented 6 years ago

As for the not directly related idea if you are around the kotlin slack or somewhere we could talk about it as I'm not sure I understood what you mean.

detouched commented 6 years ago

It will end up being a string in the header so for now I think it will be OK. The only thing that could worry me is the authorization header name but as far as I know is pretty standard.

Yeah, it is pretty standard. I agree that it'd be cool to import it from somewhere rather than using a local string, but there's no suitable library in the classpath, and it's not worth pulling one just for that. So keeping it as is for now.

if you are around the kotlin slack or somewhere we could talk about it

Sure thing. I'm there with the same nickname detouched. I found one Javier Diaz and one j-diaz - not sure which one is yours :)