wot?
Was it clearer the second time? 
yes 
but I don’t get the point why. my case: I don’t want to enter user&pw everytime I’ll have a look on syncthing and making my ui public. I just need to use the api (secured by a key)
You could always run Syncthing through a proxy layer, e.g. sit it behind nginx. Then do evil stuff like get nginx to specify the username+password when it forwards connections…
if I was a technical minded maybe… but what about emily b. from a.?
imho the api and the gui are completely different features for completely different usecases. (see above) I’d like to build up a online-syncthing management Platform which I could run 24/7 on a server. for that purpose I ONLY need the api and not the Gui…
Whoevever she is, she probably isn’t writing a client which uses the REST API, so it isn’t an issue for her .
The GUI and REST API do the same thing. They are covered by the same authentication mechanisms.
Besides, you should really be using SyncTrayzor, which handles the GUI authentication without you having to input anything.
but she is able to run syncthing on her home devices…
yes sure but why “opening” the Gui if I only need the api and vice versa?
also remote devices?
…and Syncthing will listen on 127.0.0.1, and no-one else will be able to connect to it. Therefore she won’t need a password. Therefore everything is fine.
It is ONLY when you want to connect to Syncthing from another machine that you need to mess around with passwords, and ‘emily b. from a.’ won’t be doing this, so this entire discussion is completely irrelevant for her.
That’s not English, and I don’t understand it.
You misunderstand. With SyncTrayor you can set a GUI password, and you’ll never have to type it into anywhere.
I’m not really following the stuff above, but the GUI is only a thin layer on top of the API. Basically the GUI is just the API + some static files. If you don’t load those static files, there’s no cost to the GUI. So disabling the GUI and keeping the API doesn’t make much sense to me.
ok… maybe you misunderstood… my plan is to build up a little platform to manage all my (not emilys) devices remote from one place. for that purpose I need the api - and only the api. I would not like to setup a GUI password only to use the api for remote access via forwarded port…
He wants:
- The GUI to be only accessible to localhost, no password
- The REST API to be accessible from anywhere, and require an API key
I understand all of that. Now please read what I said.
I did - and it doesn’t makes it better 
I think you did not get my intents 
my idea is to use my local GUI without setting up a pw, syntrayzor or any other stuff. I’m fine with it like it is! why installing nginx, synctrayzor or other stuff?
I just thought of forwaring a port up to use the api 
Well it obviously isn’t fine the way it is, otherwise you wouldn’t be asking for things
harhar… 
I’m serious though. You’ve got a problem. I’m suggesting solutions. Then you come back with “I’m fine like it is! I don’t need solutions”.
If you’ve got a problem, why don’t you need a solution to it?
Yeah, the API and GUI is the same thing from an authentication point of view. And we can’t separate authentication vs not-authentication for different source IP:s currently. If you want to protect the API from outside access, you need to enable authentication (and then use API keys in the management thing).
@canton7, @Eddy2909: you’re talking around each other. Be more patient. 
1 Like
please read that post again
your solutions don’t fit my needs - thats the problem
my thought wasnt to separate auth for different sources. my thought was to seperate auth of api and gui on different ports…
is my english really such a **** ? 
In what way? Both provide a means of authenticating the REST API, and being able to access the GUI without entering a password.