Restricting access to your domain-server


#1

Last week we added the ability to lock off a domain-server’s private admin pages by allowing only certain users or roles to administer a given domain-server. This setup requires OAuth against data-web from the domain-server.

Because OAuth won’t be possible yet from user domain-servers, today we added the option to lock off the domain server using basic HTTP authentication. Many of you who have configured routers via a web interface will be familiar with this flow. The browser will present you with a dialog requesting a username and password - it will store that username and password for a period of time so you do not have to re-enter every time you go back to the domain-server.

Here is how to specify which usernames (with associated passwords) can administer your domain-server. Note that this requires no correlation with your High Fidelity username and password (in fact I’d recommend you do not use the same combination of username/password for both).

The file you’ll be looking to change is your domain’s JSON config file. It’s entirely possible you don’t have a JSON config file for your domain-server yet. The easiest place to store your config file is in the domain-server resources folder. When run, the domain-server by default attempts to load a file named “config.json” in its resources directory.

To that JSON file, you will want to add the following key and value setup

"basic-auth": {
  "$username": {
    "password": "$password"
  }
}

Where $username and $password should be replaced by your desired username and password.

For example - here is the entire config.json file I use for my local domain-server.

{
  "basic-auth": {
    "birarda": {
      "password": "secretpassword"
    }
  }
}

Now nodes can still reach my domain-settings on 40100, but nobody can simply log in and kill the nodes connected to my domain or change my domain settings.


#2

@Ai_Austin once the updates deploy (specifically if you’re using the stack-manager for your stack) - you should be able to use this guide in order to lock off your domain-server as you’ve referenced in other threads


#3

Great thanks @b that sounds like it will do the trick. I made the changes ready for this in the config.json file on our setup. Works fine… after I got my { } brackets right :slight_smile:


#4

Do you expect the Windows stack manager GUI “Stop” button to actually stop the various assignments (and domain server) or just restart them. it seems to stop them briefly and then they restart.

The same happens when I use the “Kill” X on an assignment. I see it go off the nodes list, appear in the Queued assignment’s for a few seconds and then reappear in the main active nodes list with a fresh uptime … and another X for kill (without any username password being asked for as noted before).


#5

looks very similiar to htaccess and htpasswd from apache :slight_smile:


#6

hi @Ai_Austin the “stop” button issue I have down as an issue to be fixed and should be shortly.


#8

If the config.json dont work, try this. So no spaces and no tabs at the begin !

{
“basic-auth”: {
“birarda”: {
“password”: “secretpassword”
}
}
}


#9

@Richardus, depending on the script editor you use it may of messed you up. e.g. I use Sublime and when I copy and paste it auto spaces everything correctly for me.


#10

Useing notepad++, i think i can say thats pretty the standard for people that need a better editor and people that know notepad++ anyway it works for now.

Add: checked, the settings and editor again. after some sleep :slight_smile: and now things work fine. :blush: problem fixt.


#11

Sorry to say, but after @thoys told me it, this whole login screens seems not more then a joke.
it scared me a bit now i know everybody could read my login details for the stack manager webpage. the config.json is public available and the login details are stored inside that file.
I know its alpha, and always useing different password and logins. but still this need to be fixt soon. after its fixt people can update the password and have a safer login screen.

Make config.json not readable from the web, is the most simple solution. I thats possible.


#12

@Richardus where is your config.json file?

Your config.json file should be inside the resources folder of your domain-server, but not the resources/web folder of your domain server. config.json will not be reachable if it is not inside the web folder.

settings.json is a file that contains settings that the domain server passes out to nodes. These are publicly available settings that do not need to be secured. settings.json is specifically not behind the username and password you set in the config. The ability to change those settings is restricted to someone who is authenticated to the domain-server.

The ability to change those settings is restricted to someone who is authenticated to the domain-server, but in a read-only fashion they should be accessible to anybody - regardless of what is in config.json.


#13

Oh - I see now that it is incorrectly appending all of those config values to response in settings.json.

Implementing a fix now.


#14

Okay - I merged a fix for this. Once @leo deploys a new stack-manager (and you download it) you will notice now that locahost:40100/settings.json does not return anything in your config.json file (which should be found in your resources directory.

If you had set any domain settings from the web (these are just audio settings for now) then you will need to re-set them from the web interface.


#15

Thanks,

We need to wait for @leo now to bring a new stack manager online. just checked , but no change right now. ill check tomorrow again.


#16

Since this is a change to the domain server, there is no need for a new stack manager. Your stack managers automatically download the latest domain server and assignment client builds, once your stack manager updates you’ll all be fixed. Please let me know of any issues.

L


#17

Ok. i dont see my password and login anymore in the json file. GREAT. :sunny:


#18

@leo, is it possible that this fix broke the “name this location” ? because the id: is set in config.json to.


#19

Note that the “name this location” problem was there BEFORE this change (in Windows)


#20

Maby the changed something, i made a location yesterday. that i use now to get home. but cannot make any more new ones. But good to know its not because the latest change.


#21

Make sure you guys rename config.json to settings.json after the stack manager self updates, otherwise your settings will simply be ignored. In mac that file lives in ~/Library/Application Support/High Fidelity/Stack Manager/resources — I can’t recall the path for Windows so please whomever has it around or knows it by heart let us know.

And if you haven’t done so already, you need to add your domain id to the settings.json file. Please see this thread for details:

https://alphas.highfidelity.io/t/howto-make-name-this-location-working-on-windows-i-did-the-following/920/8

L