Tasmota: Allow multiple roles on web interface (ex: read-only)

[hb020]

Have you look for this feature in other issues and in the wiki?

It is related to #1550, but I that ticket was closed due to inactivity, not because it was thoroughly thought through. Not knowing if opening a new issue, or appending to that closed ticket is better, I decided to open a new one. Feel free to correct me.

Is your feature request related to a problem? Please describe.

The web interface knows only 1 role: admin. I have 2 issues with that:

1. Vulnerability:
   
   
   
   • Context: We do not have SSL, so everything web server related is in the clear (on the LAN).
   
   
   • Problem: If one wants to secure the device, one has to set a web admin password. However, once we have set that password, we can also no longer read from or interact with the device via the web interface. Therefore: we are required to use that admin password also for reading sensors and writing to actuators, which we do much more often than undertaking admin activity. Thereby, we are radically increasing opportunities to sniff the admin password. And once you have the admin password, you can do all kinds of nasty things like changing the firmware.
   
   
2. Standard practice: It is standard practice on a lot of software to allow at least 2 roles: 'admin' and 'user' and/or 'view'

Describe the solution you'd like

Please allow 2 or 3 roles on the web interface.

• Admin
• Viewer: read only on status info (ex: /cm?user=viewer&password=XXXX&cmnd=status%208)
• User: Interaction like switch toggle etc, but no admin actions like WiFi settings or firmware updates. I personally do not need that (yet), but I imagine some do, and I see the usefulness of it.

Describe alternatives you've considered

Other channels than web APIs. I know that Tasmota started out with MQTT. But I like it for the other features: it has OTA, is versatile, and it has a rather nice web interface.
Just in case someone wants to tell me to use MQTT: I do not want to use MQTT anymore. Been there, done that, ran away screaming. I use WEB API (REST) wherever possible now. And before I get comments on that, I have created, and still maintain, a large scale commercial product that uses MQTT extensively. Seen enough of it to not want that anymore.

Additional context

I can help coding it, it is not that complicated. It gets more difficult if you want it to work on more than 2 roles, and/or on other endpoints than /cm?cmnd=status{....}, but even that is doable. If you factor out the authentication and authorization to one central location, we might even be able to lower the overall code size. And it would raise the config size by only a couple of bytes (20 bytes or so per role).

[Jason2866]

The main goal of Tasmota is using the device via mqtt. This will not be changed.
I think the project owner will not invest time in coding Web user roles.
You could do a PR, if code size increase is minimal there is a chance to get merged.

[hb020]

I think the project owner will not invest time in coding Web user roles.

Have seen that in other replies.

You could do a PR, if code size increase is minimal there is a chance to get merged.

Understood, will free up some time for that.

[joba-1]

IMO this whole admin thing that already is in tasmota wastes space and (much more important) creates a false sense of security. It wont get better with roles.

If you need security:

• add another ssid to your wlan router.
• put all iot devices in that ssid's wlan subnet
• only allow iot admins to use that ssid/subnet
• run a webserver (e.g on a rpi zero) proxying requests from the normal, more public ssid subnet to the iot ssid subnet.
• this webserver can handle transport encryption, secure authentication, role administration, nice icons for different devices, cool css formatting, history charts, whatever...

[Jason2866]

@joba-1 I agree 100% with you in aspect security. A ESP8266 will never be secure with a accessible Web Frontend!
A usage scenario could be setting up the device and locking it only for viewing and using (switching).
Nothing can be changed by accident -> kids

[joba-1]

Just out of curiosity: what are the drawbacks of mqtt that made you run away screaming?

To give context: I think mqtt is a very good way to keep status of not-always-on devices (without wearing their flash/eeprom - if they even have that) and to allow changing their status while they are off for the next time they come back.

I admit though, this is not the normal tasmota usecase, just my own on some external sensors. With tasmota it only has the advantage of being more lightweight than most other protocols. But if you implement everything in mqtt and other protocols (like html) that already defeats the point a bit...

[hb020]

@joba-1 What you are suggesting is adding a reverse proxy in front of them, acting like an API manager. That is possible of course. But it all goes over the air after that. Other SSID or not. And there we have another vulnerability (especially with 2.3.0, see KRACK), so in the end that kind of setup is not really much more secure. And yes, I use a separate SSID and a separate VLAN.

@Jason2866 I could work towards that. The software already has provisions for that, (see HttpOptions and see type in StartWebserver(int type, IPAddress ipweb)) , although that is not used fully, as only HTTP_MANAGER_RESET_ONLY and HTTP_MANAGER are used. I could complete that. Just need a way to switch between modes run time, and not only setup-time.

EDIT: I just see that I CAN switch to user mode via command "webserver 1". Just need to find out what the functionality is when I do that (I think that command 'STATUS...', used for reading the sensors, is not available then), and how to get back to 'admin mode' run time, without having to use MQTT or re-flashing.

@joba-1 about MQTT: the security part is really bothersome, as is the scalability (especially with a broker like mosquitto). MQTT is nice for devices on low quality (mobile) links, but networks get better all the time. The typical use case for the Sonoff devices is static installations with a link to a local hub, not mobile. Once you've seen the power of APIs/REST, together with API managers, you do not want to go back. It is just much easier to work with HTTP APIs, and can be very lightweight as well.
I'm not saying it is not possible, just that I've had too many bad experiences with MQTT. Plus, my network is fully 1-wire (for various wired sensors) + REST (for WiFi and for wired) + SNMP (mainly for network infra stuff), so I prefer not to add a broker in there for something that I can also do via other means.

[joba-1]

Thanks @hb020 ,
regarding security: I dont really agree that cracking a wlan is somewhere near the same league as plain text sniffing, but I see your point and you are right that wlan encryption also is not 100% secure (well, basically nothing is). Just wanted to point out there might be better solutions available for your problem.

regarding mqtt: I see, you are talking of existing api protocols/libraries. For that I agree, http is just much more common, so much more stuff is based on that. But technically there is nothing that prevents you from implementing an api that exists for http on top of mqtt as well.

[hb020]

Here's what I found so far about the built-in 'USER' and 'ADMIN ' modes of the web server:

• Default mode is ADMIN
• One can switch to USER mode via web command webserver 1.
• in USER mode, only the root page is available, all other pages and functions are blocked (once setup is over)
• in USER mode, on the root page, the admin/password combination is still needed, when set. There is no 'user' password.
• the root page allows Toggle, Dim, Color and RF switching functionality, plus status reading for all sensors. The output when using the 'status' m parameter is not JSON, but a mix of HTML and text.
• it is not possible to go back to ADMIN mode via web commands, one needs MQTT or re-flashing via serial. Web-initiated OTA is no longer possible.

I personally see 2 problems with that (in a non-MQTT situation). If one is in USER mode, ..

1. The sensor status is not really usable via standard HTTP methods. JSON would be better, like the no longer accessible STATUS commands would do. This can be solved rather easily via new parameter on the root page, that passes through to the standard status command handler. Very little code needed.
2. Putting the device in USER mode forces you to wipe and re-flash via serial if you want to use ADMIN again or want to flash a new firmware, removing a lot of the upsides of Tasmota to me. To alleviate this, I see 3 options, that I would like to propose and put up for vote:
   
   
   
   1. Add an easily accessible UI 'Lock down' button that calls the webserver 1 command behind the scenes. In reply to this action, a one time, system generated, write-down passphrase is shown. Going back to ADMIN mode will go through a specific URL, using that passphrase. The passphrase will need to be created random or (preferably not) calculated by the system from MAC address or so. Consequences: one string in settings, and relatively little code is needed.
   
   
   2. As above, but request the passphrase from the user. Consequences: one string in settings, and a little bit more code is needed (additional field in UI).
   
   
   3. Set up and maintain separate user and admin passwords, and allow all or partial admin functionality even when in USER mode. And maybe add that UI 'Lock down' button. Consequences: one string in settings, and again a bit more code than the other options is needed (additional field in UI, more URLs to protect, comparing between user and admin).
   
   

The last is more standard, and is probably easier to explain to users, but will add more code. Option "i" is also fine by me, but will require an explanation, preferably run-time. Option 'ii' has no real advantage.

I like that 'lock down' button. Make it easy for people to secure their device a bit more. Right now it is rather hard to find out how to do it, so I can bet not many people do it.

What would be your preferences?

[Jason2866]

I will not use this function since i am a mqtt guy and dont use webfrontend. So i am the wrong person to ask... I could imagine, best change for merge has the solution with smallest code size increase

[mike2nl]

• About the web frontend:
  There are more users like me who are using that web frontend.
  But i use it in a safe network with connect to all other networks which have i-net connetion.
  All web commands used by another system which is are PLC's.
  The web frontedn can be used in much more cases like mobile phones or self made web pages.

So far my two cents to it.

[hb020]

Just to let you know I'm working on options i) and iii) from the post above (4 days ago). Will compare code footprint and ease of use.

[hb020]

PR made. Neither option i) nor iii) behave great. Both have counter intuitive edges, but the latter gives more freedom of use, and is more intuitive, hence the PR for option 3. And it only adds 208 bytes to sonoff.bin (Orig: 543 040, New: 543 248)

[ascillato2]

Closing this issue as the PR has been made for reviewing. Thanks for sharing your ideas.