uptime-kuma
uptime-kuma copied to clipboard
initial support on domain expiry monitoring
👉 Delete this line if you have read and agree our pull request rules and guidelines: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma
Description
Fixes #944
Type of change
Please delete any options that are not relevant.
- Bug fix (non-breaking change which fixes an issue)
- User interface (UI)
- New feature (non-breaking change which adds functionality)
- Breaking change (fix or feature that would cause existing functionality to not work as expected)
- Translation update
- Other
- This change requires a documentation update
Checklist
- [x] My code follows the style guidelines of this project
- [x] I ran ESLint and other linters for modified files
- [x] I have performed a self-review of my own code and tested it
- [x] I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
- [ ] My changes generate no new warnings
- [ ] My code needed automated testing. I have added them (this is optional task)
Screenshots (if any)
Please do not use any external image service. Instead, just paste in or drag and drop the image here, and it will be uploaded automatically.
Thanks for the pr.
- WHOIS servers have rate limit. I think the expiry date has to be cached.
- According to this list https://data.iana.org/TLD/tlds-alpha-by-domain.txt, there are nearly 1500 TLDs. I believe that it is hard to test all TLDs and new TLDs keep launching. I understand this feature won't be perfect, but in the other hand, users will not understand and will keep opening bug report in this repo.
- Please use the existing date library
dayjs
instead of addingmoment
.
As I remember, @karelkryda is working on his own library for this feature?
Yes, I started working on the universal WHOIS library. The procedure is slow because there are a huge number of TLDs. Many of them have differently named value keys, other required data does not return at all.
Currently, I would need help with domains for testing. See the discussion at my repository.
We are clearing up our old Pull Requests and yours has been open for 3 months with no activity. Remove stale label or comment or this will be closed in 2 days.
up
Up
Status of this PR?
It would be great if this feature is available.
@alexandernst @tiagogoncalves-7egend @initpwn
Please refrain from posting +1
/ requests for update-things on PRs, as this makes reviewing it even harder.
For updates, there is a subscribe to this PR button at the top.
We use 👍🏻 on PRs to prioritise work.
@CommanderStorm I commented with "up" in order to remove the Stale
tag.
It would be great if this feature is available.
Why ?
Closed by bot unexpectedly.
My comment is still valid: https://github.com/louislam/uptime-kuma/pull/1775#issuecomment-1157283008
And RDAP should be the way to go: https://github.com/louislam/uptime-kuma/issues/944#issuecomment-1560479896
Also I don't think domain name fit into Uptime Kuma monitor's logic, because I don't think we actually need to query it every 60s. Deregistering a domain I believe it is very uncommon.
What we should do is, get the expiry date and cache it. And send a notification to tell the user that the domain will be expired in 30 days. Just like what we did with HTTPS cert.
- I have many examples in the professional world where the team responsible for renewing the domain is on vacation and the site becomes inaccessible.
- I think we need to make only one request per day maximum
@mabed-fr It was not I meant. Maybe my explanation was not good. Let me show you a "real life" example:
Assume that you have a chocolate🍫, the expiry date is Dec 1, 2025. You want to eat it before the expiry date.
- Check the expiry date every day
- Mark the expiry date in your calendar in Dec, 2025
Method 1 or 2 is better?
I understand well, but I'm expressing my perspective, if uptime-kuma verifies it for me, that's fine with me. You can use the same mechanism as for certificates, that would be sufficient.
I am going to close this PR. Sorry for the work that went into this PR.
At this time, I don't believe the problems that exist with the current implementation^1 will be resolved via this PR. We can reopen the PR if this changes or continue the discussion in a new PR ^^