Suggestion: zeroconf announces

My routine when I create a new share is to run syncthing, kill it, replace the localhost IP address with a LAN address, change the listening port if needed and go create a static file in avahi-daemon to advertise the service. This works but the avahi part is a bit cumbersome, esp. when AFAIK announcing https:// URLs is not standard (or supported in Safari), so in addition to that I have to take care of setting up a redirection in a local http server.

I’d love to see syncthing take care of the dns-sd registration and be able to upgrade the connection to https all by itself.

I hope this makes sense. Feel free to disregard :slight_smile:

This is to announce the GUI connection to the browsers on the local network? Seems like something we could do.

Yes that’s it.

It’s me and my Pi 3s again :wink: I have users accounts, netatalk and syncthing on the Pi. Users (or me as admin) manage sync through their workstations. We use macs, Safari includes a bonjour tab, it makes things quite easy.

1 Like

Broadcasting gui url woulnd’t be zeroconf as the ST security would then rely on empty user credentials then weak ones when it comes for many people to select a user name+password. This would be a too easy way to gain access to the conf and then all data on this machine. Instead of having this automatically done (or rely on user be prompted to do so which is really a security concern for non aware people), I like knowing ST won’t do this at all and I access the conf from local only, eventually with the help of some yet configured remote access as ssh, vnc, desktop share. I someone argued this preconfigured access would then yet be badly secured/too permissive, I’d reply there’s no need to add weakness to weakness. I’m not a security guru at all, rather a concerned user, so please don’t read this comment as impolite and point where I misunderstand.

Anyway, the current epoch1070 way to do is a bit tweaky and remains easily feasible by anyone.

When you install syncthing you’re using empty credentials to connect to the GUI, not? The difference with zeroconf and without is this, for me:

  • With it: “There’s a link in your name in the bonjour tab now. click it.”
  • Without: “type in Not your page? Humm. Try 8385 then. Ok, let me see.”

This has nothing to do with login credentials, and Zereconf is a local network service only.

Correct, but the GUI only allows connections from localhost - so noone outside of your PC can access Syncthing.

If Syncthing allowed passwordless access from other machines by default, that would be a huge security hole - you’re giving away everything on your PC to anyone on your local network.

All right then.

Lets change my request to: have an option to advertise the service in the config tab. And it is disabled by default, and won’t enable until a password is defined.

At least I wouldn’t have to keep tabs of port numbers in syncthing conf and keep them in sync with a freaking static avahi service snippet.

Because the avahi conf is static, I’m starting to standardize, like user1 is 8384, user2 is 8385 … this is pure waste of time.

(BTW. The install in my case, is on a headless server. Nobody logs in except admin. is useless to me.)

So you could easily wedge something on top that does this via the rest API (works out who’s who) and performs the announcements.

Yes, I suppose it is not that hard. Perhaps the http → https upgrade would be a bit tricky?

Basically I have no idea of what’s in the API, nor how to use it from a script of some sort. And I could continue like that :slight_smile:

If the admin burden becomes too heavy I’ll do something, for sure. Like a conf generator, that’s old school enough not to require an API.

Furthermore, when you install ST, you already are at the local machine keyboard, physically or remotely, so why not going on doing your way to customize your setup.

Although, we could imagine an option where ST would be only allowed to bcast its conf url when https_only+username+random_100chars_password has been entered (not a problem regards to FFSync eg)… although over although, I feel lan broadcast only would then be not enough: it should be nice ST would advertize it’s gui url to any remote (read even on wan) selected devices when added… oooch, we’ll need a zeroconf gateway setup there (or UPnP required ?)

The API is well documented in the docs site and I don’t see why upgrading http to https would be a problem.

Ok. I’ll do my homework then. Case closed.

I still think this may be a valid request. I looked into it a little bit and for example my wireless hotspots announce their admin UI. They certainly require authentication.

I previously looked into using DNS-SD (mDNS, Zeroconf, Bonjour, whatever) as the local discovery protocol but couldn’t easily make it work for whatever reasons. Looking now, I think some of the obstacles have been removed or I understand them better (multicast in Go, for example).

It could be attractive to move local discovery completely to DNS-SD and also announce our admin UI that way. If nothing else it’s a little bit more “standard”.

1 Like

… so that it handles multiple instances on the same machine ?

That was one of the problems preventing it. But now it actually works to listen for multicast on the same port as something else. FWIW our current local discovery does this as well, over IPv6. The downside with DNS-SD is that it requires multicast over IPv4 as well, which was something that wasn’t very reliable when we used that a few versions back.