Reset Index when GUI Authentication is activated

Hello.

I’m trying to delete the index of a directory following this instructions. That has worked flawlessly in the past.

Today I got a “Not Authorized” as an answer. Maybe because GUI Authentication has recently been configured. So I’ve tried to add user and password to the command, but to no avail. Can somebody help me with the syntax, please? :flushed:

curl -X POST -H "X-API-Key: ABCDEF-...-ABCEDF" --form user='someuser' --form password='supersecret' http://localhost:8384/rest/system/reset?folder=BLAH

That looks correct enough to me, and you shouldn’t need to the user stuff at all as long as the API key is correct. I’m not sure of the --form-user and so on though, I usually just set it up as https://user:password@localhost:8384/... and let curl take care of the rest.

(Why are you resetting the index?)

Thank you for the lightning fast response! :sunny:

Using the credentials as you suggest make much more sense. Thanks for that, too.

It still does not work but I have to look further into the ID-thing. The output of curl suggests, its not the user authorization that fails, but that there is something wrong with the ID. And that although the ID has been copied from the GUI > Actions > Show ID. Hmm…

[admin@...U4 ~]# curl -vv -k -X POST -H "X-API-Key:ABCDEF-...-ABCDEF> https://user:password@127.0.0.1:8090/rest/system/reset?folder=BLAH
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8090 (#0)
* Server auth using Basic with user 'syncthing'
> POST /rest/system/reset?folder=BLAH HTTP/1.1
> Host: 127.0.0.1:8090
> Authorization: Basic c3luY3RoaWsomethingTM2NC1zdi00
> User-Agent: curl/7.43.0
> Accept: */*
> X-API-Key:ABCDEF-...-ABCDEF
> 
< HTTP/1.1 401 Unauthorized
< Content-Type: text/plain; charset=utf-8
* Authentication problem. Ignoring this.
< Www-Authenticate: Basic realm="Authorization Required"
< X-Content-Type-Options: nosniff
< Date: Sun, 24 Jul 2016 09:04:58 GMT
< Content-Length: 15
< 
Not Authorized
* Connection #0 to host 127.0.0.1 left intact

And to your question why I’m doing this:
tl;dr
Resilience tests.

Long boring story:
The organization I work with is syncing data since 15 years in all sorts of ways to all sort of operating systems. Syncthing is by *far* the most satisfying solution I’ve ever came across.
It’s meshed, it traverses different networks, it’s stable, it’s reliable, it’s stable, it’s light weight, it works with high latency lines (like from Continents to ships that sometimes have to uplink at all), it’s encrypted, it’s stable, it’s remote administrable, it’s free (!), it’s open source, it’s still stable.
In three words? It’s just great. Two Words? Simply great.

Only now and then there is a condition in which it will fail. The most common (in the organization I am working with): renames. The second most common: Things that happen while one node is offline.
Once a directory is renamed from, say “RESULTS” to “results” mayhem ensues. I though it might kind of work when only case sensitive filesystems are involved, but even HFS+ to NTFSv5 have problems. By manually cleaning up (via ssh) and then giving syncthing the hint (via REST) to ditch the index things can work again.
So I am writing a documentation for my colleagues to help them try and figure out what to do.

The API-Key in your code is either badly obfuscated or wrong (wrong format).

It seems you are using your Device ID as the API Key.

The real API-Key can be found in the field “Api Key” in the Settings.

I obfuscated it since I assume this is a secret. I am not sure how to exploit it, but then…

I’m closing this topic since I am not sure what the problem is. Now, … how do I close it…

But you left the auth string intact which can be decoded and exposes your username and password.

I assumed that to be a hash… :smiley: ok. Thanks. I’ll edit that out. Done.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.