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 a custom provider #546

Closed
augustabt opened this issue Jul 22, 2023 · 6 comments · Fixed by #560
Closed

Add a custom provider #546

augustabt opened this issue Jul 22, 2023 · 6 comments · Fixed by #560
Labels
design? The next step is to reflect upon the information and come up with a good design enhancement New feature or request

Comments

@augustabt
Copy link

For my use case being able to configure a custom provider would be useful. It would basically be a http provider like ipify, but with the ability to use an env variable to configure any url.

@favonia
Copy link
Owner

favonia commented Jul 23, 2023

@augustabt Thank you for your feedback. Could you possibly provide more detail about why you might want to use a non-Cloudflare server? I'm quite curious.

PS: ipify was still an option but deprecated because the server does not seem to be actively maintained.
PPS: I might have to think about the configuration interface a bit.

@favonia favonia added enhancement New feature or request design? The next step is to reflect upon the information and come up with a good design labels Jul 23, 2023
@augustabt
Copy link
Author

@favonia for sure. My specific use case is I am running a kubernetes cluster with the pods subnet exposed to a vpn I can connect to. Since the pod ip address can change I wrote a service that gets all the currently active pods and exposes one of their ip addresses that can then be used for dns. I think a more common use case would be someone who has a specific provider they want to use instead of cloudflare.

@favonia
Copy link
Owner

favonia commented Aug 19, 2023

@augustabt Sorry for the long delay. I am starting to implement this. The current design is to have something like url:https://.... Do you have any suggestion about the input format?

@favonia
Copy link
Owner

favonia commented Aug 28, 2023

@augustabt I can still change the interface before the release of the next version. Please let me know if you think the implementation should be changed. Thank you!

@Aiakio
Copy link

Aiakio commented Aug 30, 2023

@augustabt Sorry for the long delay. I am starting to implement this. The current design is to have something like url:https://.... Do you have any suggestion about the input format?

For now, im using:

 - IP4_PROVIDER=url:https://api4.ipify.org
 - IP6_PROVIDER=url:https://api6.ipify.org

successfully.

I think its alright if documented properly. Altough i would think that a format like this:

 - IP4_PROVIDER_URL=https://api4.ipify.org
 - IP6_PROVIDER_URL=https://api6.ipify.org

would be a little easier to understand / read.

@favonia
Copy link
Owner

favonia commented Aug 31, 2023

@Aiakio Thanks!

I think its alright if documented properly.

Got it. Here's the current documentation (truncated because it's a bit long). I think I'll tweak it a bit, maybe adding some warnings about using HTTP (not HTTPS).

  • url:URL (🧪 experimental)
    Fetch the content at a URL via the HTTP(S) protocol as the IP address. The provider format is url: followed by the URL. For example, IP4_PROVIDER=url:https://api4.ipify.org will fetch the IPv4 addresses from https://api4.ipify.org, a server maintained by ipify. ⚠️ Currently, the updater does not [...]

Although i would think that a format like this: [...]

I get that it would be shorter. I'd like to have an unambiguous prefix so that we can have new custom providers in the future, for example a generic parser to extract the ip field from https://api.cloudflare.com/cdn-cgi/trace. It seems too fragile to check whether something is a valid URL before parsing it, as some provider name might accidentally be an URL. One possibility is to use URLs for everything (as shoutrrr or apprise) but it's too late to change that. 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design? The next step is to reflect upon the information and come up with a good design enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants