User roles proposal #454
User roles proposal #454
Conversation
| <xs:sequence> | ||
| <xs:element name="Name" type="xs:string"> | ||
| <xs:annotation> | ||
| <xs:documentation>Name of the editable user level.</xs:documentation> |
There was a problem hiding this comment.
Currently ONVIF have Administrator, Operator, User, Anonymous, Extended User levels defined and the access permissions for these user levels also pre-defined. So Name parameter in EditableUserLevel should not conflict with any of the existing ONVIF Pre-Defined user levels so that the behavior of the ONVIf pre-defined user levels should not be changed. I also do not know the current usage of Extended User level pre-defined.
There was a problem hiding this comment.
In my vision, they do not conflic, because to use the EditableUserLevels the Userlevel must always be set to extended. But I understand that this may lead to tricky names. So, let's gather the opinion of other members.
|
Is it possible not to include whitespace changes or similar changes in the PR? It makes it terribly difficult to find the actual changes in the documents. If its a clean up we want, we should do that change in a separate PR so it can be accepted quickly so future changes include them by default. |
doc/Core.xml
Outdated
| <para>A device that signals support for the Default Access Policy via the respective capability shall support at least one user of each user level Administrator, Operator and User.</para> | ||
| </section> | ||
| <section> | ||
| <title>Editable user levels</title> |
There was a problem hiding this comment.
Should this section define the expected behavior if a device receives a function it does not know (ex. new API call added, but device running older firmware)
There was a problem hiding this comment.
If you do not mind, I'd prefer to add a dedicated error in §8.4.10.2 (i.e. Set editable user level)
There was a problem hiding this comment.
During the San Diego F2F meeting, we agreed that we are going to ignore the unknown function
| <xs:documentation>Name of the editable user level.</xs:documentation> | ||
| </xs:annotation> | ||
| </xs:element> | ||
| <xs:element name="Functions" type="tt:StringList"> |
There was a problem hiding this comment.
Should we consider more compact data representation? For example grouping methods by namespace:
- namespace 1
- function 1
- function 2
- function 3
- namespace 2
- function 1
- function 2
| @@ -65,6 +65,14 @@ | |||
| </author> | |||
| <revremark>Add support for WebSocket protocol and token authorization.</revremark> | |||
| </revision> | |||
| <revision> | |||
| <revnumber>25.06</revnumber> | |||
There was a problem hiding this comment.
Should this not change Version and Date? or are we waiting until the changes are merged?
| @@ -10,7 +10,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO | |||
| --> | |||
| <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" targetNamespace="http://www.onvif.org/ver10/device/wsdl"> | |||
| <wsdl:types> | |||
| <xs:schema targetNamespace="http://www.onvif.org/ver10/device/wsdl" xmlns:tt="http://www.onvif.org/ver10/schema" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" elementFormDefault="qualified" version="23.12"> | |||
| <xs:schema targetNamespace="http://www.onvif.org/ver10/device/wsdl" xmlns:tt="http://www.onvif.org/ver10/schema" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" elementFormDefault="qualified" version="25.06"> | |||
| <listitem> | ||
| <para><emphasis>onvif:User</emphasis> : the predefined role corresponding to the User | ||
| user level. Users with User user level and extended users with onvif:User role shall | ||
| be idempotent.</para> |
There was a problem hiding this comment.
| be idempotent.</para> | |
| be unchanged.</para> |
There was a problem hiding this comment.
What I am trying to state is that they should have the same access. Maybe idempotent is too mathematical, but I do not think that unchanged is the right word to express the concept.
There was a problem hiding this comment.
During the San Diego F2F meeting, we agreed to use identical
I do agree with this comment there was a lot in this PR not related to the topic that was highlighted as changed. I do not believe ether that it was deliberate. I choose in this instance to identify grammar or spelling mistakes that the opportunity presented for correction and highlight them as suggestions for update and fix that should improve the quality of the final specifications. |
Co-authored-by: Kieran McCartan <[email protected]>
Co-authored-by: Kieran McCartan <[email protected]>
Co-authored-by: Kieran McCartan <[email protected]>
Co-authored-by: Kieran McCartan <[email protected]>
Co-authored-by: Kieran McCartan <[email protected]>
Co-authored-by: Kieran McCartan <[email protected]>
| </xs:annotation> | ||
| </xs:element> | ||
| <xs:element name="Functions" type="tt:StringList"> | ||
| <xs:annotation> |
There was a problem hiding this comment.
For the predefined userroles like onvif:Administrator etc., the functions parameter can be empty ? or do we have fill this for pre-defined userroles also ? can we clarify this somewhere.
Initial proposal for implementing editable user levels. They are necessary for SOAP over SCTP in WebRTC sessions.