Plans to save bot config to a json file for cross browser support?

[coltoneshaw]

Is your feature request related to a problem? Please describe. Right now if you setup a multi-bot frequi instance you add each bot within the UI, and setup the CORS accordingly. This seems to be stored in localStorage. So, if you access your UI from another browser, device, or reset cache all the bots are required to be re setup again.

Describe the solution you'd like Ideally this would be stored in a config.json, or added to the primary UI's config.json possibly under the api_server config. This could be an array of bot objects stored in the primary config and loaded when the UI loads. This would additionally require a username / password to access the UI itself since all data would be immediately accessible when the UI loaded.

Describe alternatives you've considered There are no clear alternatives that I've found.

Additional context I've glanced at the code itself and am curious if it's something that I would be able to handle and if it's something that you see as within the scope of this project.

[xmatthias]

while i can see a possibility to export the UI config - it's for sure not going to be done the way you're proposing (by uploading it to one of the bot's api's). From a security perspective, that would be the worst thing you could do (we'd upload all access keys to this one bot - which means it could control all other bots "On it's own" - obviously assuming you're using different passwords for each. Even if you do (which you shouldn't) - if the bots run on different servers (a very common deployment pattern), they won't know about each other - unless we store all url's (and corresponding keys) on one server.

The only way i can imagine this to be done somewhat safely is by having a "export UI configuration" button in the UI, which will download the configuration, and have a corresponding "import configuration" which allows you to load this again. This moves the "keeping the configuration secure" to the user - which is however better if documented properly than permanently storing it on one of the bot's servers.

[coltoneshaw]

Thanks for your reply! I'm not sure an import/export button would solve this problem. That would definitely be useful but for the cross-browser/device support it adds an additional step of storing your UI config somewhere safe, but also accessible by all your devices.

I think this still could be possible and maintain secure bot access. What I'm thinking is the below. I'm sure there is room for the security to be improved. These are just rough thoughts initially.

Config Storage

• Create a config block within the config.json existing file, separate from the api_server on the main bot. This would allow you to persist settings for your FreqUI within a config file.
• Your config would get loaded in on the restart of your freqtrade instance and not able to be edited within the UI.

Probably something like:

{
    // ...
    "webserver" :{
        "preconfigured_bots" : [
            {
                "name" : "bot1",
                "url" : "http://bot1:8080",
                "username" : "bot1",
                // the password would be a salted and encrypted version of the password
                "password" : "ii_9DBkIqeqi6Hhbc3_81eDGI6Acv1NcqtiWMaR259"
            }
        ],
        "login" : "supersecretlogin",
        "password" : "anotherSecretPass"
    }
}

Bot Management

• You would not be able to edit the bot values within the UI itself if you set up bots within the config since these are loaded on restart of the container.
• This would not "auto-detect" new bots or anything along those lines. It's purely a static config once the UI is loaded and to update these config bots you have to update your config.json and reload
• You could still have localStorage bots that pull from the storage and are saved within the browser. The stored bots would just show alongside the localStorage bots.

Security

• The primary bot that hosts the UI wouldn't have all the API passwords / URLs. You'd store the passwords encrypted and salted in the config itself so no single place could access everything.
• With this, you'd need an additional Login page for the whole UI. This would include a username/password that can be stored and used alongside the salted password to retrieve the data for API calls to update the UI.
• You can even take this a step further and introduce 2FA or a separate pin into login and detrimental bot actions like selling a position.
• For additional security, you could use the domain in the request as an additional layer for salting the password.
• You could even add a force sell / cancel flag to disable those features within the main UI itself.

[xmatthias]

So to summarize, we'd have one place that holds all the credentials (the config) for all other bots, have this "exposed via an endpoint to the UI (you'll have to have the credentials in the browser in the end), and which holds the jwt credentials (or whatever else) to all other bots.

So from a security perspective - this is the worst possible scenario if you ask me.

Nothing you put in front of this "one place" will make it secure enough to justify such an architecture - not for an open source project we expect people to deploy themselves, where we have no control over the way this endpoint is exposed. I'd for one, never run this directly on the internet (not this, but also not the bot API itself). While we can document it this way - we cannot prevent it from happening should people choose to do so anyway. While i can control this for myself - we have to design the bot/api/UI in a way to keep it secure even if people chose to go the easy route and ignore this advise.

You also always have to consider that it's possible to have bugs (either in the code that exposes / protects this - or in libraries responsible for that). Not even paid penetration tests will give you any guarantee - all they'll tell you is that "we didn't find anything" - not "this is unbreakable".

So to be honest, i'm not convinced - and if you think carefully, you'll only have to do this setup once - not every day - so it's a lot of hastle, a lot of code to maintain, and a lot of added risk for very little benefit.

[pnmice]

It would be cool to save added bots configs without passwords in frequi. @xmatthias Do you know a workaround for now, how to save and restore the added bots in a different browser? Thanks

[xmatthias]

you can always manually copy/paste the data from the local store in the browser.