Duplicate Service URLs are possible

[d-Rickyy-b]

Describe the bug

It is possible to create two (or more) services that have the exact same service url. There should be a check so that service URLs are not duplicated.

To Reproduce

Steps to reproduce the behavior:

0. Use version v0.90.74 (Docker)
1. Open the admin dashboard
2. Create a new service - call it "test" (Service Name). It will auto fill the Permalink URL field with "test"
3. Save and go back to create another service
4. Call it "test" again, it will also have "test" as Permalink URL autofilled
5. Open the regular status page (https://host.tld/) and try to open both services individually

Expected Behavior

There shouldn't be a way to assign the same service url for two services.

1. I'd expect the application to throw an error and tell me to use another service url because the other one is already in use. Service URLs should be unique so that we can visit both services individually.

2. I'd also expect the UI to automatically append something like -1 to the Service URL field automatically during the creation process if the URL is already taken. Or a combination of name & group names. But that's of course just a convenience feature.

Actual Behavior

I can add as many services with the exact same service URL as I want. This becomes an issue if you have several services with the same name but in different groups (e.g. one URL for the "API" group, one for the group "website"). Both check different services. But if we didn't manually change the Permalink URL, we can only view one of both services

---

Workaround

You can work around this issue by manually setting a custom Permalink URL for your service.

Impact

This could lead to confusion (Both services - although different - show exactly the same data). This could also lead to feeling of a false certainty (no issues displayed although service offline).

---

Screenshots

I used two different domains "example.com" and "example1.com".

If you have any questions regarding this issue, feel free to ask.

[adamboutcher]

But you might be testing different things on the same endpoint URL such as an API that accepts different POST requests.

[d-Rickyy-b]

But you might be testing different things on the same endpoint URL such as an API that accepts different POST requests.

Thanks for your comment. As I noted in my initial comment: But if we didn't manually change the Permalink URL, we can only view one of both services

So there is no way for us to manipulate a 'service' again without renaming one. Because both service sites are reached through the same URL /<service_name>.

[adamboutcher]

Ah, you mean that you can give the same service name, I thought you meant the end-point URLs...

Yes maybe having a duplicate check on the Service Name would be useful.

[github-actions[bot]]

This issue hasn't had any updates in a while. If this is still a problem, please create a new issue.

[d-Rickyy-b]

This issue is still relevant

[github-actions[bot]]

This issue hasn't had any updates in a while. If this is still a problem, please create a new issue.

[d-Rickyy-b]

It's still relevant!

[github-actions[bot]]

This issue hasn't had any updates in a while. If this is still a problem, please create a new issue.

[d-Rickyy-b]

It's still relevant!

[github-actions[bot]]

This issue hasn't had any updates in a while. If this is still a problem, please create a new issue.

[d-Rickyy-b]

It's still relevant!

[github-actions[bot]]

This issue hasn't had any updates in a while. If this is still a problem, please create a new issue.

[d-Rickyy-b]

It's still relevant!

[github-actions[bot]]

This issue hasn't had any updates in a while. If this is still a problem, please create a new issue.

[d-Rickyy-b]

It's still relevant!

[github-actions[bot]]

This issue hasn't had any updates in a while. If this is still a problem, please create a new issue.

[d-Rickyy-b]

It's still relevant!

[codybennett]

This is some serious dedication to keeping the issue from being stale for a year!

For what it’s worth, you’ll likely have more traction on one of the main/active forks of this repo at: https://github.com/statping-ng/statping-ng

[d-Rickyy-b]

This is some serious dedication to keeping the issue from being stale for a year!

For what it’s worth, you’ll likely have more traction on one of the main/active forks of this repo at: https://github.com/statping-ng/statping-ng

Thank you, I know about statping-ng. Actually, I am no longer interested in using statping altogether. There are way better alternatives out there. I'm mainly keeping this issue alive for others to see that this project is abandoned.

[dnsk8dn]

hi Rickyy. Could you inform some alternatives to use them Statping-NG?

[d-Rickyy-b]

Hi @dnsk8dn I am using https://github.com/louislam/uptime-kuma for a while now and it works like a charm and has a very active community.

[github-actions[bot]]

This issue hasn't had any updates in a while. If this is still a problem, please create a new issue.

[d-Rickyy-b]

It's still relevant!

[github-actions[bot]]

This issue hasn't had any updates in a while. If this is still a problem, please create a new issue.

[d-Rickyy-b]

It's still relevant!

[github-actions[bot]]

This issue hasn't had any updates in a while. If this is still a problem, please create a new issue.

[d-Rickyy-b]

It's still relevant!

[d-Rickyy-b]

Actually, I really don't care getting this fixed anyway, because I am using uptime-kuma, so I'll just close it on my own.