ESP32 Forum

Okay. What is your question? For what it's worth, ESP-IDF does not have infrastructure for multiple users inherently, but that doesn't stop you from associating an user and associated permissions with a connection in your application code itself.

Hi,

My question is as follows:

1. What is the best and safest to implement this functionality?
2. Note that users will connect to the ESP32 device over the WiFi connection and will attempt to configure these parameters.
3. Different levels of users should be able to configure different sets of parameters (in a hierarchical format).
4. My question is concerning what is the best way to implement this using the inherent functionality? Do you have some examples that I can see? Some example code?

I would be very grateful to have your views on it?

Best regards
Robin

Webserver.
RESTful needs a webserver and is about how the interface is presented and manipulated really rather than being an answer itself (e.g. I could use HTTP GET to update parameters but that is not RESTful).

Lets say that your webserver is index.html with linked pages /users.html and /parameters.html
You can add new user on the user's page etc.
Now your RESTful api might be /api/v1/users & /api/v1/parameters
Your HTML page would present the data & allow editing. Using Javascript you would POST the updates to /api/v1/users & /api/v1/parameters (I usually allow GET to update as well as whilst not RESTful allows browser testing)
Typically RESTful would have /api/v1/users/1 ... /api/v1/users/n where n is your last user index (don't forget /login).
Accessing /api/v1/users/1 might return {"name": "john", "access": 1} where as /api/v1/users would return all users.

Now you have an API and a set of webpages for presentation and editing.
Next you need the persistent database.
I would be inclined to use the ESP IDF virtual file system linked to FLASH for the users. Just a regular file but shadowed.
I would be tempted to use the IDF NVS for the parameters especially if you update regularly. A file would be ok if you do not update often. You could also use NVS for users, little more complicated (your key would need to be made unique,perhaps by adding entry number) but gives you power fail update security.

This now leaves you wondering about access security.
The simplest approach would be to have login return a unique key. Any parameter transaction must offer that key. If you HTTPS then that is a start. If you work for the CIA then you might need more.
Let me know if I earnt a merit grade

PeterR has illustrated a way, but it's hard to say what way suits you, as your question is super-general. (Compare it to asking 'What tool is the best tool to make food?') As such, it would be hard to give you something that would work best for your particular situation, so instead of giving you one, I'll posit how I would get this started instead. (This duplicates some of PeterR's approaches, I'm just including them here as well for the narrative. Go read his post as well.)

As the core of your problem is the setting/getting of parameters, I'd work on that first. Define some kind of data structure that can encapsulate all the parameters you need to get/set. What that looks like depends on your needs: Does the structure need to be easily modifiable? Does it need to change at run-time? Does it need to have some parts visible/invisible dependent on other parameters? Can you get away with hardcoding that logic or do you need some domain-specific way of doing this? Also think about meta-data: you'll need to know what is accessible by what user. How are you going to define this? Do the users change? Can you hardcode this (e.g. divide users into groups and do permissions based on groups) or do you need to be able to change this per-user at runtime?

Now create an API for this data structure. Effectively something like set_param(param_name, userid) that checks if the user can access the parameter and changes it if so, or refuses if not so. Note that this API is internal to the device; it trusts the caller to put the actual proper userID into this.

If you're done with this, add a backing storage, aka how wiil these parameters get stored? You probably want NVS for this, but other options (SQLite, textfile on SD-card, ...) are also possible. Obviously, you also want to take into account what happens when the storage fails: you're implementing security here, would you want the device to suddenly be wide-open if someone pulls the SD-card or the NVS gets corrupted somehow?

Finally, you need a way to have users change this. It can be a webserver, it can be an app, it can be a command-line thing, hell, you can make it into an email responder if you want to. Important here is that you have some way of authenticating the user, by e.g. asking for a password, and somehow keeping track of the users session. That last bit is easier for some solutions than others: command-line, you can just associate the telnet connection to the user; web-based you need to do something with implementing sessions.

The rest is user-interface definition: build some comfortable interface around the API you built earlier that can make your users happy.

Agreed, the question is very general & misses the fact that RESTful is not transport but is a logical/semantic approach.
I would however disagree with the cooking analogy -

'What tool is the best tool to make food?'

Answer: Wok/Frying pan, often a roasting/baking tray, rarely a pot & never a yogurt maker.