Experimental IOTMP Proxies (TCP/HTTP) for connecting with device local network resources, i.e., devices/routers webpages, terminals, RDP, VNC, etc. These proxies requires new IOTMP client library for Linux.
Each project can now define a set of Project Roles that can be used by any member within a project.
.
Each developer/admin account can now define a set of Global Roles that can be used by any member within any project. For example, a general purpose read role that can be shared in all projects.
Project member permissions can be now established by roles in addition to custom member permissions, simplifying permissions management. All global roles, project roles, and custom permissions can be established together (if required).
Members will go to the first allowed section after login or refresh, instead to the default Project Dashboard, i.e., devices or dashboards if they do not have access to read project dashboard.
Device resource streams includes now different signals: start, stop, data, and error (on IOTMP devices), in order to keep track of streams.
Device Terminal now supports multiple concurrent sessions (with the IOTMP linux client).
Server can now use wildcard certificates, stored as *.mydomain.com on the certificates folder. Provisioning wildcard certificates over Domains section is not possible.
Internal socket server can now filter socket connections based on IP address. Used at this moment internally for proxies security.
Fixed
Very high loads over websockets could cause a crash under some circumstances.
Automatic transition to newly created resources when they are nested more than 2 levels (i.e., while creating a new project member).
Potential crash with multi-thread product initialization at startup.
Switching between projects, or opening/closing projects reporting forbidden under some circumstances.
Set projects displayed on proxies (proxies does not support projects).
Missing selectors when configuring specific token permissions, i.e., over a proxy.
Access Tokens now are limited to the project scope where they are defined.
Great! Important functionality. It got much better!
Will “Developer” users be able to create/enable “Project Member”? If yes, great!
I still think administering the Thinger Server with a “Domain Admin” account to create devices, users, projects… something risky, as we don’t have Two-Factor Authentication (2FA).
I could be wrong, but it would feel safer to operate the Server in production with the “Developer” account that doesn’t allow changing HOST and domain settings.
But like I said, I could be wrong… except for the need to implement a Two-Factor Authentication (2FA).
Could you give more details about this functionality?
I remember that it would be important to change the device statuses to indicate, for example, when the device is disabled. With this, the Administrator could differentiate the status “Disconnected” from “Enabled/Dsabled”. I even mentioned it in this post:
Is it related to the device’s playload (Arduino-Thinger)?
It was a doubt I had (if I understand this point correctly). It was unclear whether establishing broad permissions for a “Project Member” would cause a security breach. Ex: Allow a “Project Member” to create and delete devices.
Sorry if I misunderstood this point.
A complement to the new user access rules functionality would be:
Hide dashboard tabs for specific users.
Example:
Painel = Access for all users
Settings = Some users only (eg tech support)
Glad you like it! For managing multiple projects/members, which is becoming habitual on our client deployments, it is required role management to centralize all permissions
Yes, it should be able to create new members without admin or admin domain permissions. Will add 2FA on our roadmap.
It is something more internal related to device_resource_stream event, which now can receive different signals according to the stream state (start, stop, data, error). It is used internally for keeping track of remote socket states/terminals.
Ok, will add it to the queue.
No…
Member permissions are constrained to the project and cannot be used for anything outside them. But, if you give them access to create or delete devices in the project, it will work as expected, because you may need developer or management roles with these permissions. This change is related to the Access Tokens. From now own, access tokens only grant access to the projects they are included, and no other external resources.
This was an issue related to the new IOTMP protocol being tested.
A suggestion:
Allow FileStorage files (JSON) to be used as a data source for the HTML Widget.
Ex:
I manipulate JSON files by NodeRED and save to FileStorage.
It would be very interesting to use JSON data Stored in FileStorage ( In my case, the data could not be stored on a Device Property or Bucket) to fill in information from a standard HTML file (.html) that I use in the HTML Widget.
.
.
