Option to send new spots up to DX Cluster

ian commented

2025-10-14 02:52:42 +00:00

Owner

This should be user toggleable (and persisted to local storage). It should replace spotting into the local database when used, so we don't get a duplicate spot back from the cluster.

Cluster will require a new connection to spot as the DE user. Syntax is here: https://wiki.dxcluster.org/wiki/Getting_and_posting_DX

User will need to provide an SSID for logging into the cluster.

Add CAPTCHA or similar to prevent bot abuse from the web UI.

This should be user toggleable (and persisted to local storage). It should *replace* spotting into the local database when used, so we don't get a duplicate spot back from the cluster. Cluster will require a new connection to spot as the DE user. Syntax is here: https://wiki.dxcluster.org/wiki/Getting_and_posting_DX User will need to provide an SSID for logging into the cluster. Add CAPTCHA or similar to prevent bot abuse from the web UI.

ian added the

enhancement

maybe

labels

2025-10-14 02:52:42 +00:00

~~ian referenced this issue from ian/field-spotter 2025-10-19 14:06:28 +00:00~~

Authenticate with APIs for more features #5

ian added this to the 1.1 milestone

2025-11-10 21:26:46 +00:00

ian modified the milestone from 1.1 to 1.2

2025-12-23 22:27:08 +00:00

ian commented

2026-01-10 10:00:14 +00:00

Author

Owner

Need to figure out how to do authentication against a cluster node. There are several options, but to best prevent abuse/botting I think we need to ask the user for a password and only post to cluster if we can positively identify them.

Ideally I'd like to avoid storing usernames & passwords in Spothole, having to implement our own auth flow, user account creation/deletion, setting & changing passwords etc. But we will have to see how feasible it is to avoid that.

As a basic implementation we could require that the user already has set up a password on the cluster, then prompt them for that password during spotting, and obviously we can only post to cluster if that password matches. This would mean quite a lot of initial setup hassle for the user, as they would have to set this up in advance via their logging software or via telnet, but would mean Spothole doesn't have to store any user data, and it does protect the system from abuse.

Maybe we can do that as a first step, then later provide UI for managing your password on a cluster (still telnet commands mediated by the server). Or maybe we will end up having to store something within Spothole.

One weakness of this is that the user will need to have set a password on the cluster(s) that Spothole uses; I don't believe passwords are synced around the cluster at all. If the user's "home" node that they use from a traditional logger is not one Spothole connects to, they will have to set their password again on the other node. Spothole also doesn't currently make it particularly obvious which cluster node it's using.

Maybe the outcome of this is that I should run my own cluster node for Spothole. That's not ideal in terms of extra admin overhead for me but does mean that we have one consistent place to manage password auth. It also means that if other cluster sysops don't like the idea of being able to post from a website, or an abuse/botting problem arises via Spothole, other sysops could filter out stuff coming from Spothole and it wouldn't taint another innocent node.

Need to figure out how to do authentication against a cluster node. There are several options, but to best prevent abuse/botting I think we need to ask the user for a password and only post to cluster if we can positively identify them. Ideally I'd like to avoid storing usernames & passwords in Spothole, having to implement our own auth flow, user account creation/deletion, setting & changing passwords etc. But we will have to see how feasible it is to avoid that. As a basic implementation we could require that the user already has set up a password on the cluster, then prompt them for that password during spotting, and obviously we can only post to cluster if that password matches. This would mean quite a lot of initial setup hassle for the user, as they would have to set this up in advance via their logging software or via telnet, but would mean Spothole doesn't have to store any user data, and it does protect the system from abuse. Maybe we can do that as a first step, then later provide UI for managing your password on a cluster (still telnet commands mediated by the server). Or maybe we will end up having to store something within Spothole. One weakness of this is that the user will need to have set a password on *the cluster(s) that Spothole uses*; I don't believe passwords are synced around the cluster at all. If the user's "home" node that they use from a traditional logger is not one Spothole connects to, they will have to set their password again on the other node. Spothole also doesn't currently make it particularly obvious which cluster node it's using. Maybe the outcome of this is that I should run my own cluster node for Spothole. That's not ideal in terms of extra admin overhead for me but does mean that we have one consistent place to manage password auth. It also means that if other cluster sysops don't like the idea of being able to post from a website, or an abuse/botting problem arises via Spothole, other sysops could filter out stuff coming from Spothole and it wouldn't taint another innocent node.

ian commented

2026-01-10 13:53:26 +00:00

Author

Owner

So it looks like users generally can't set up a password on a cluster node themselves - they have to email their desired password in plaintext to the sysop who sets it for them. A design choice from a different era of the internet for sure.

As far as I can tell the vast majority of cluster nodes allow posting spots without needing a password.

So it looks like users generally *can't* set up a password on a cluster node themselves - they have to email their desired password in plaintext to the sysop who sets it for them. A design choice from a different era of the internet for sure. As far as I can tell the vast majority of cluster nodes allow posting spots without needing a password.

ian changed title from ~~Option to send new spots upwards~~ to Option to send new spots up to DX Cluster

2026-01-11 10:23:24 +00:00

ian commented

2026-01-11 10:40:41 +00:00

Author

Owner

I think we have a couple of fundamental decisions to make here.

Cluster password required to spot:

No: Matches how most nodes currently operate. Open to abuse, maybe more so because Spothole's web UI is more ripe for drive-by spam botting compared to using telnet.
Yes: Virtually eliminates abuse. Requires a user to know what cluster node Spothole connects to and email its sysop for a password. (Automating this email has been discussed, I think it's a bad idea as sysops will use "is this email written by a real human" as part of their judgement on whether to create the account.

Run a DXSpider node for Spothole:

No: Less hassle. Don't have to convince other node sysops to allow me to peer with them and that Spothole won't be a source of abuse. People running their own copies of Spothole may not want to use my cluster node anyway, so any solution we implement must work for any cluster node.
Yes: Any account/password setup could be done by me rather than burdening other sysops with it. In the event of sustained abuse it's only Spothole's node that would be tainted, not some innocent third party's, and spots from it could quickly be filtered out by other nodes.

Fun to be debating this while the cluster network is seeing multiple abusive bot posts per minute anyway.

Setting this to "blocked" for now as I have no clear decision on either of these questions. Advice welcome!

I think we have a couple of fundamental decisions to make here. Cluster password required to spot: - *No*: Matches how most nodes currently operate. Open to abuse, maybe more so because Spothole's web UI is more ripe for drive-by spam botting compared to using telnet. - *Yes*: Virtually eliminates abuse. Requires a user to know what cluster node Spothole connects to and email its sysop for a password. (Automating this email has been discussed, I think it's a bad idea as sysops will use "is this email written by a real human" as part of their judgement on whether to create the account. Run a DXSpider node for Spothole: - *No*: Less hassle. Don't have to convince other node sysops to allow me to peer with them and that Spothole won't be a source of abuse. People running their own copies of Spothole may not want to use my cluster node anyway, so any solution we implement must work for any cluster node. - *Yes*: Any account/password setup could be done by me rather than burdening other sysops with it. In the event of sustained abuse it's only Spothole's node that would be tainted, not some innocent third party's, and spots from it could quickly be filtered out by other nodes. Fun to be debating this while the cluster network is seeing multiple abusive bot posts per minute anyway. Setting this to "blocked" for now as I have no clear decision on either of these questions. Advice welcome!

ian added the

blocked

help wanted

labels

2026-01-11 10:40:46 +00:00

ian modified the milestone from 1.2 to 1.3

2026-01-16 08:48:07 +00:00

Rows
Columns

Option to send new spots up to DX Cluster #39