CN112307486A

CN112307486A - Authority obtaining method, equipment and system

Info

Publication number: CN112307486A
Application number: CN201910690284.4A
Authority: CN
Inventors: 王建平; 张许坚; 冯涛
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-07-29
Filing date: 2019-07-29
Publication date: 2021-02-02

Abstract

The application provides a permission obtaining method, a device and a system. In the authority obtaining method, a client device sends a request message, wherein the request message carries a data node and an authority request parameter which are used for indicating operations to be performed by the server device, the operations are directed at, the authority request parameter is used for requesting an authority result, and the authority result indicates authority information of the user for executing the operations on the data node; the server-side equipment receives the request message and generates a response message, wherein the response message comprises an authority result; and the server side equipment sends a response message, wherein the response message comprises an authority result. By the method, whether the data node in the request message has the authority for executing the operation or not can be carried in the response message by the user, and the authority information does not need to be confirmed to an administrator again, so that the method is beneficial to reducing the complexity of network management.

Description

Authority obtaining method, equipment and system

Technical Field

The application relates to the field of communication, in particular to a permission obtaining method, device and system.

Background

The network management protocol provides a set of network device management mechanisms, and a user can add, modify, delete and acquire data information such as configuration and state of the server device through the client device by using the set of mechanisms.

The Network Configuration Protocol (NETCONF) is a brand new Network management Protocol formally proposed in 2006 by the Internet Engineering Task Force (IETF) NETCONF working group, and is defined in IETF Request for comments (RFC) 6241. The protocol provides a set of management mechanism of the network equipment, the network management system can use the mechanism to inquire, increase, modify and delete the configuration of the network equipment and obtain the configuration and state information of the network equipment, the mechanism adopts a client side and a server side mode to carry out the configuration management of the network equipment, the client side equipment sends a request message to the server side equipment, the server side equipment receives and receives the request message, generates a response message and sends the response message to the client side equipment, and the client side equipment receives the response message.

Meanwhile, the NETCONF protocol defines a set of Access Control models (NACM) for defining Access Control mechanisms of an operation layer and a content layer. In the defined access control mechanism, a client device and a server device establish a session, the server device performs access authority control based on user information using the client device and a defined NACM authentication rule list, after receiving a request message of the client, determines the authority of the user according to a data node and an operation in the request message, if the authority exists, the requested operation is executed, if the authority does not exist, the operation is not executed, and the operation can be query, modification, deletion or the like. And the server equipment generates a response message according to the operation result and sends the response message to the client equipment. The authority information is usually managed by a super administrator or an authority administrator, and an ordinary user does not have the authority for authority configuration or inquiry.

In some cases, when a user operates a server device through a client device, a corresponding operation is a read permission type operation such as an inquiry operation, and data node data information contained in a response message returned by the server device is empty, the user cannot know whether permission information needs to be confirmed again with a super administrator or a permission administrator because of no permission or no data, which leads to complex network management.

Disclosure of Invention

The application provides a permission obtaining method, a device and a system, which are used for determining the operation permission of a user using client equipment in the operation process and reducing the times of permission information confirmed by the user and a permission administrator.

The technical scheme provided by the embodiment of the application is as follows:

in a first aspect, a method for acquiring a right is provided, where the method includes:

the method comprises the steps that a client device generates and sends a request message to a server device, wherein the request message carries a data node and an authority request parameter aiming at an operation to be performed by the server device, the authority request parameter is used for requesting an authority result, and the authority result indicates authority information for a user using the client device to perform the operation on the data node;

and the client equipment receives a response message, wherein the response message carries the permission result.

Therefore, the client device can feed back the authority information of the user to the data node to be operated to the user using the client device in time, the times of the authority information confirmed by the user and an authority manager are reduced, and the complexity of network management is reduced.

In a possible manner, the operation may be an operation of querying, modifying, or deleting, and the corresponding permission information is whether querying is possible, whether modifying is possible, whether deleting is possible, or the like.

In a possible manner, when the operation is a read operation, the operation may further be a query (get), a query configuration (get-config), an incremental synchronization (sync-increment) or a full synchronization (sync-full), and the application is not limited in particular.

Therefore, after the client device sends the request message, the permission information of the user for executing the operation on the data node can be simultaneously obtained in the received response message sent by the server device, so that the management complexity is reduced, and the difficulty of permission management is reduced.

In a possible manner, before the client device sends the request packet, the client device sends a capability notification message to the server device, where the capability notification message indicates that the client device has a capability of requesting a permission result.

In a possible manner, before the client device sends the request packet, the client device receives a capability advertisement message sent by the server device, where the capability advertisement message carries an authority response capability indicating whether the server device supports the capability of returning the authority result.

Therefore, after the client device confirms that the server device has the permission response capability, the request message is sent, and the problem that the client device blindly sends the request message carrying the permission request parameters to cause request failure can be avoided.

In a possible manner, the request message is a request message of a representation layer state transition configuration protocol RESTCONF or a request message of a network configuration protocol NETCONF, and the method is supported to be used under various management protocols.

In one possible approach, the permission request parameter is included in a uniform resource identifier or an extensible markup language of the request message.

Based on the possible mode, on the basis of carrying out negotiation, communication and authentication by using the existing NETCONF or RESTCONF, the existing mechanism of the network management protocol can be multiplexed by supporting the permission request parameter carried in the request message in the NETCONF or RESTCONF, a set of mechanism does not need to be redefined, and the complexity of the scheme is reduced.

In a second aspect, a method for acquiring a right is provided, where the method includes:

the method comprises the steps that a server-side device receives a request message sent by a client-side device, wherein the request message carries a data node for indicating an operation to be performed by the server-side device, the operation is directed at, and an authority request parameter, the authority request parameter is used for requesting an authority result, and the authority result indicates authority information for a user to execute the operation on the data node;

the server-side equipment generates a response message, and the response message carries the authority result;

and the server equipment sends a response message to the client equipment, wherein the response message carries the permission result.

Therefore, the server-side equipment can feed back the authority information of the user to the data node to be operated to the user using the client-side equipment in time, and the complexity of network management is reduced.

In a possible manner, the operation corresponding to the operation may be an operation of querying, modifying, or deleting, and the corresponding permission information is whether querying is available, whether modifying is available, whether deleting is available, or the like.

In a possible manner, when the operation is further a read operation, the operation may be a query (get), a query configuration (get-config), an incremental synchronization (sync-increment) or a full synchronization (sync-full), and the application is not particularly limited.

In a possible manner, before the server device receives the request packet, the server device receives a capability advertisement message sent by the client device, where the capability advertisement message indicates that the client device has a capability of requesting a permission result.

In a possible manner, before the server device receives the request packet, the server device sends a capability notification message to the client device, where the capability notification message carries an authority response capability indicating whether the server device supports the capability of returning the authority result.

Based on the possible mode, on the basis of carrying out negotiation, communication and authentication by using the existing NETCONF or RESTCONF, the permission request parameters carried in the request message are supported in the NETCONF or RESTCONF, the existing mechanism can be reused, a set of mechanism does not need to be redefined, and the scheme difficulty is reduced. And after the client device sends the request message, permission information of the user for executing the operation on the data node can be simultaneously obtained in the received response message sent by the server device, so that the management complexity is reduced, and the difficulty of permission management is reduced.

In a third aspect, a client device is provided, including:

a memory for storing a plurality of data to be transmitted,

a processor coupled to the memory, the processor to execute the computer readable instructions in the memory to cause the client device to:

generating and sending a request message to a server device, wherein the request message carries a data node and an authority request parameter which indicate the operation to be performed by the server device, the authority request parameter is used for requesting an authority result, and the authority result indicates authority information for a user using the client device to perform the operation on the data node;

and receiving a response message sent by the server side equipment, wherein the response message carries the permission result.

Therefore, the client device can feed back the authority information of the user to the data node to be operated to the user using the client device in time, and the complexity of network management is reduced.

In a possible manner, the operation may be an operation of querying, modifying, or deleting, and the corresponding permission information is whether querying is possible, whether modification is possible, whether deletion is possible, and the like.

In one possible approach, before the client device sends the request message, the processor is configured to execute the computer-readable instructions in the memory to cause the client device to:

and the client equipment sends a capability notification message to the server equipment, wherein the capability notification message indicates that the client equipment has the capability of requesting the permission result.

In one possible approach, before the client device sends the request message, the processor is further configured to execute the computer-readable instructions in the memory to cause the client device to: and receiving a capability notification message sent by the server side equipment, wherein the capability notification message carries permission response capability, and the permission response capability indicates whether the server side equipment supports the capability of returning the permission result.

In a fourth aspect, a client device is provided, where the client device has a function of implementing the client device in the first aspect or any one of the optional manners of the first aspect. The device includes at least one module, where the at least one module is configured to implement the method for acquiring rights provided by the first aspect or any one of the optional manners of the first aspect.

In a fifth aspect, a server device is provided, which includes:

a memory for storing a plurality of data to be transmitted,

a processor coupled to the memory, the processor configured to execute the computer readable instructions in the memory to cause the server device to:

receiving a request message sent by client equipment, wherein the request message carries a data node for indicating the operation to be performed by the server equipment, the operation, and an authority request parameter, the authority request parameter is used for requesting an authority result, and the authority result indicates authority information for the user to execute the operation on the data node;

generating a response message, wherein the response message carries the permission result;

and sending a response message to the client device, wherein the response message carries the permission result.

In a possible manner, the operation may be an operation such as querying, modifying, or deleting, and the corresponding permission information is whether querying is possible, whether modification is possible, whether deletion is possible, or the like.

In a possible manner, the operation is further a read operation, and may be an operation such as query (get), query configuration (get-config), incremental synchronization (sync-increment) or full synchronization (sync-full), and the application is not limited in particular.

In one possible approach, before the server device receives the request packet, the processor is configured to execute the computer readable instructions in the memory to cause the server device to:

and sending a capability notification message to the client device, wherein the capability notification message carries permission response capability, and the permission response capability indicates whether the server device supports the capability of returning the permission result.

In one possible approach, before the server device receives the request packet, the processor is further configured to execute the computer readable instructions in the memory to cause the server device to: and receiving a capability notification message sent by the client device, wherein the capability notification message indicates that the client device has the capability of requesting the permission result.

A sixth aspect provides a server device, where the server device has a function of implementing the server device in the second aspect or any optional manner of the second aspect. The device comprises at least one module, and the at least one module is used for implementing the authority acquisition method provided by any one of the above second aspect or the second aspect.

In a seventh aspect, a communication system is provided, where the communication system includes a client device and a server device, the client device performs the method according to the first aspect or any one of the options of the first aspect, and the server device is configured to perform the method according to the second aspect or any one of the options of the second aspect.

Drawings

Fig. 1 is a schematic diagram of a communication system provided in an embodiment of the present application;

fig. 2 is a flowchart of a method for acquiring a right according to an embodiment of the present application;

fig. 3 is a flowchart of a communication method according to an embodiment of the present application;

fig. 4 is a schematic diagram of a format of a request packet according to an embodiment of the present application;

fig. 5 is a schematic diagram of a format of a request packet according to an embodiment of the present application;

fig. 6 is a schematic diagram of a format of a response packet according to an embodiment of the present application;

fig. 7 is a schematic diagram of a client device according to an embodiment of the present application;

fig. 8 is a schematic diagram of a client device according to an embodiment of the present application;

fig. 9 is a schematic diagram of a server device according to an embodiment of the present application;

fig. 10 is a schematic diagram of a server device according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

The terms referred to in the present application are explained below:

NETCONF the NETCONF protocol is a brand-new network configuration protocol formally proposed by the IETF working group of NETCONF in 2006, and is defined in the IETF Request for comments (requests for comments) RFC 6241. The protocol provides a set of management mechanisms for the network devices, which the network management system can use to query, add, modify or delete the configuration of the network devices to obtain the configuration and status information of the network devices.

YANG (Yet antenna Next Generation): YANG is a data modeling language for NETCONF, proposed by the NETMOD working group and published in IETF RFC 6020.

REST presentation layer State transition (Representational State Transfer): a web software architecture style is intended to facilitate the transfer of different software/programs to and from each other in a network, such as the Internet. Is based on a set of constraints and attributes determined on top of the hypertext transfer protocol HTTP, a software build style designed to provide web services. Network services that match or are compatible with this architectural style (abbreviated REST or restul) allow clients to issue requests to access and operate network resources with uniform resource identifiers, URIs, consistent with a predefined set of stateless operations.

RESTCONF presentation layer state transition configuration protocol: RESTCONF is a protocol that satisfies the RESTFUL architecture style, and is defined in RFC 8040. The protocol is based on HTTP bearers, has access to the data defined in YANG and stores Datastore using the data defined in NETCONF. The data defined by the YANG model is edited and inquired through the operation of HTTP, and the POST operation can also be used for executing the remote procedure call RPC method defined by the YANG model.

Hereinafter, the system architecture of the present application is exemplarily described.

Referring to fig. 1, an architecture diagram of a communication system according to an embodiment of the present application is shown.

The communication system provided by the embodiment of the application can comprise a client device 10 and a server device 11, wherein the client device 10 is in communication with the server device 11.

The client device 10 is a device in which a rest conf or NETCONF protocol client is deployed, and may be, for example, a mobile phone, a Personal Computer (PC), a Tablet PC, a notebook computer, a super mobile PC, a personal digital assistant, or a server device.

The server device 11 is a device that is deployed with a server supporting the rest connect or NETCONF protocol, and the server device may be a network device of the Internet Protocol (IP) network device, a Wavelength Division Multiplexing (WDM) network device, an Optical Transport Network (OTN) network device, or a server, and the embodiment of the present invention is not particularly limited. The configuration data and the state data of the server device are stored in the storage unit of the server device 11, and the client device 10 may operate the data stored in the server device 11 by initiating a request packet, where the operation may be an operation such as querying, modifying, or deleting.

In the existing implementation scheme, before the connection between the client device and the server device is established, user authentication is performed, and after the user authentication using the client device passes and the connection between the client device and the server device is established, the connection information, such as session, includes user information, so that all interactions between the client device and the server device before the connection is disconnected have user information. When the request packet sent by the client device 10 to the server device is a read operation type request packet, it may include multiple operation objects, that is, request read operations for multiple data nodes. When a user who uses the client to access does not have corresponding operation authority on a certain data node, the information of the corresponding data node part in a response message returned by the server is null; the information returned by the server device when the data node is the data information is consistent with the information which is returned by the user when the user has the read operation authority on the data node, so that the user cannot judge whether the corresponding data node information is empty because the user does not have the authority or the server does not have the corresponding data. The user is required to confirm again with the administrator having the authority management, resulting in complicated network management.

The communication system shown in fig. 1 is provided by applying the method of the embodiment of fig. 2 described below, and is only briefly described here.

The client device 10 shown in fig. 1 generates and sends a request message to the server device 11, where the request message carries an operation to be performed by the server device 11, a data node corresponding to the operation, and an authority request parameter. After receiving the request message, the server device 11 analyzes the request message, performs authentication according to the user information, the data node and the operation information using the client, determines whether to execute the operation according to the authentication result, generates and transmits a response message, where the response message carries permission information indicating whether the user has an operation corresponding to the requested data node.

The method flow of the present application is exemplarily described below. Referring to fig. 2, the figure is a flowchart of a rights acquisition method provided in an embodiment of the present application. As shown in fig. 2, the interaction of the method mainly includes a client device and a server device, the client device and the server device can access each other, the client device can be a client 10 in the system architecture shown in fig. 1, and the server device can be a server 11 in the system architecture shown in fig. 1, and the method can include the following steps:

s201: the client device sends a request message to the server device.

In the embodiment of the application, the client device sends a request message to the server device, and the request message carries a requested operation, a data node targeted by the operation and an authority request parameter. The permission request parameter may be, for example, "access-permit" or other self-defined parameters, which are not limited in the present application, the permission request parameter may be defined in, for example, an RFC ietf-netconf-acm YANG file, and a method for defining the parameter may refer to a method defined in RFC6241 and an example of RFC6243, which is not described in detail in the present application.

Optionally, the requested operation is an operation such as query (get), modify (update), or delete (delete), and the application is not particularly limited.

Optionally, when the requested operation is a read operation, the read operation may include operations such as query (get), query configuration (get-config), incremental synchronization (sync-increment) or full synchronization (sync-full), and the application is not particularly limited.

Optionally, before the client device sends the request packet to the server device, in order to support the corresponding capability, the client and the server need to notify the capability supported by themselves when establishing a session. As shown in fig. 3, once the NETCONF session is established, the client and the server send hello messages of the client to the opposite end to notify the capabilities supported by the client and the server. After the Hello messages are exchanged, the client sends RPC request messages to the server, and the server responds RPC-reply response messages for each RPC request message.

In an example, the hello message of the capability advertisement sent by the client device to the server device carries the permission response capability, where the permission response capability may be "access-limit" or other self-defined capability, and the application is not particularly limited.

In an example, the hello message of the capability advertisement sent by the server device to the client device carries the permission response capability, where the permission response capability may be "access-limit" or other self-defined capability, and the application is not particularly limited.

Optionally, the request message is a request message supporting the rest conf protocol, see fig. 4, which is a schematic format diagram of the rest conf protocol request message. In the figure, the request message may include an operation method (method), a URI, an HTTP protocol version (version number), a header-field name (header-name), an optional request message body (optional request body), and the like. The operation method defines a type of an operation performed on data of the server device, where the operation type includes, for example, operations such as query (get), create (post), update (put), change (patch), or delete (delete), and the application is not particularly limited.

Optionally, in the request message of the RESTCONF protocol, the permission request parameter is contained in a URI, which in one example may be "http:// 192.168.12.100:80/RESTCONF/data/huawei-system: system/systeminfoaccess-permit". Wherein 192.168.12.100 is the IP address of the server, 80 is the port number of the server, restconf/data represents that the requested data is the data of the restconf protocol, and huawei-system: system/systeminfo represents that the data node access-permit represents the permission request parameter.

Optionally, the request message is a request message of a NETCONF protocol.

In one example, see fig. 5, which is an example of a NETCONF request message. In the figure, the operation type of the protocol operation layer in the request message includes, for example, query (get), query configuration (get-config), full-scale synchronization (sync-full) or incremental synchronization (sync-increment), and the like, and the present application is not particularly limited. The management object layer in the request message indicates the data node that performs the operation, and the request message may include one or more data nodes, which is not specifically limited in this application.

Optionally, the rights request parameter is carried in an extensible markup language of the NETCONF request message.

As shown in fig. 5, in an example, the extensible markup language XML of the NETCONF request message includes the following components:

the method comprises the steps of (1) obtaining an access-permit xmlns ═ urn: ietf: params: xml: ns: yang: ietf-netconf-acm' > < access-permit >, wherein the access-permit is an authority request parameter and indicates that an authority result of a corresponding operation object needs to be obtained.

S202: and the server equipment receives the request message.

After receiving the request message, the server device needs to analyze operations required by the request message and data nodes targeted by the operations, and whether permission request parameters exist, and the server device can execute the operations required by the request message according to the parameters in the request message, such as: and authenticating the user using the client, judging whether the user has the authority to execute the operation on the data node, wherein the data node can be one or more data nodes, the method is not particularly limited, judging whether the corresponding operation needs to be executed on the data node according to the authentication result, and judging whether the returned response message needs to carry the authority result information according to the authority request parameter.

In an example, as shown in a NETCONF request message shown in fig. 5, an operation in the request message is a query (get), a data node corresponding to the operation is a group, and the request message carries an authority request parameter, in this example, the authority request parameter is "access-limit", and the server device needs to execute, for example: and authenticating the user using the client, judging whether the user has the authority of executing the query operation on the data node groups, and judging whether the query operation is executed on the data node groups according to the authentication result. If the user has the inquiry operation authority for the groups data nodes, the inquiry operation is executed for the data node groups, if the user does not have the inquiry authority operation authority for the groups, the inquiry operation is not executed for the data node groups, and because the request message carries the authority request parameters, the returned response message is judged to carry the authority result, namely the authentication result information.

For example, an authority result attribute may be defined for a generic data node that indicates whether the user has authority over the node. The corresponding permission result attribute may be, for example, access-limit or any other defined attribute, and the application is not particularly limited. The value of the attribute may be True or False, or may also be 1 or 0, for example, when the attribute value is True or 1, it indicates that the user has an authority for the node, if the identification value is False or 0, it indicates that the user does not have an authority for the node, or it may be any other value that expresses whether the node has an authority, which is not specifically limited in the present application. The definition method of the corresponding attribute can refer to RFC6020, which is not described in detail herein.

In one example, the NETCONF response message contains the following permission result examples:

the fact that the user has read permission on the vm data node is shown, and if < vmInput2 access-limit > < false > < vmInput2>, the fact that the user has no read permission on the vmInput2 data node is shown.

S203: and the server-side equipment generates a response message, and the response message carries the authority result.

In an example shown in fig. 6, the diagram is a format schematic diagram of a rest response message, and in the diagram, the response message includes a HTTP protocol version (version number), a status code (status code), a message (message), a header-field name (header-name), an optional response message body (optional response body), and the like. Wherein, the authority result can be carried in the optional response message body of the response message.

Optionally, the response message sent by the server device may also carry operation result data.

Optionally, after receiving the request message, the server device may first determine whether the capabilities supported by the server device include an authority response capability in the request message, if so, determine that the server device has a corresponding authority response capability, and if so, the response message needs to carry an authority result.

Optionally, in order to support the permission response capability, that is, the capability of returning the result of the corresponding permission after performing the corresponding operation on the corresponding data node, the server device needs to define a corresponding capability (capability) in advance. The capabilities are optional NETCONF protocol or RESTCONF protocol features and are represented by server side equipment supporting the features, and each capability is identified by a URI. For the introduction and definition of the capability, see section 9.3 of the RFC8040 protocol or the method of RFC6243, which is not described herein again.

In one example, if the permission request parameter is "access-limit," for example, then if there is a capability in the server device that contains "access-limit" in the URI, then the capability is considered to be a permission response capability.

In one example, for a server device supporting an authority response capability, a URI corresponding to the authority response capability may be, for example, < capability > http:// www.huawei.com/netconf/capability/access-limit > </capability >. In this URI, "www.huawei.com" represents the capabilities defined by Hua for a company; the "netconf/capability" is a capability under a netconf protocol, the capability name may be "access-limit" or any self-defined capability name, the present invention is not particularly limited, and the capability "access-limit" indicates a capability of supporting receiving a request message containing an authorization request parameter and returning an authorization result.

S204: and the server side equipment sends a response message, and the response message carries the authority result.

Optionally, the response message sent by the server device carries the permission result and the operation result data.

S205: the client device receives a response message sent by the server device, and the response message carries the permission result.

And the client equipment receives a response message sent by the server equipment and judges whether the corresponding node data has the corresponding operation authority or not by the user according to the authority result returned in the response message.

In an example, the permission result may be true or false, if the attribute value is true, it indicates that the user has a corresponding operation permission for the node, and if the attribute value is false, it indicates that the user does not have a corresponding operation permission for the node. If the operation result data is null and the authority result is true, it indicates that the user has the authority but the data is null. And if the result data is null and the permission result is false, indicating that the user does not have the operation permission required in the request message for the data node.

According to the method and the device, the client device generates the request message carrying the permission request parameters and sends the request message to the server device, so that the server device obtains the permission information of the user using the client for executing the operation requested in the request message on the corresponding data node after receiving the request message, and sends the message carrying the permission result to the client device, so that the client device can obtain the corresponding permission result of the user using the client device, the situation that the user is not clear whether the user has no data or does not have the corresponding inquiry permission under the condition that the response message data is empty after the read operation type request message such as inquiry is executed is generated is avoided, and the management complexity is reduced.

As shown in fig. 7, an embodiment of the present application provides a client device 700, where the client device 700 includes a sending module 701 and a receiving module 702, and performs the following operations:

a sending module 701, configured to send a request packet by a client device, where the request packet carries a data node and an authority request parameter that indicate an operation to be performed by the server device, where the operation is directed to, the authority request parameter is used to request an authority result, and the authority result indicates authority information for a user using the client device to perform the operation on the data node;

optionally, the operation may be an operation such as querying, modifying, deleting, and the like, and the corresponding permission information may be an operation such as whether querying is possible, whether modifying is possible, whether deleting is possible, and the like, and the application is not particularly limited.

Optionally, the operation may further be a read operation, including operations such as query (get), query configuration (get-config), full-scale synchronization (sync-full), and incremental synchronization (sync _ increment), which is not specifically limited in this application.

Optionally, the sending module 701 is further configured to send a capability notification message, where the capability notification message indicates that the client device has a capability of requesting a permission result.

Optionally, the request message is based on a RESTCONF protocol or a NETCONF protocol.

Optionally, the uniform resource identifier URI in the request message includes a permission request parameter.

Optionally, the XML in the request message includes a permission request parameter.

A receiving module 702, configured to receive a response packet sent by a server device, where the response packet carries the permission result.

Optionally, the receiving module 702 is further configured to receive a capability notification message sent by the server device, where the notification message includes a permission response capability, and the permission response capability is a capability that the server device supports returning the permission result.

It should be noted that, the client device 700 provided in the embodiment of fig. 7 is only illustrated by the above-mentioned division of the functional modules, and in practical applications, the above-mentioned function distribution may be completed by different functional modules according to needs, that is, the internal structure of the client device is divided into different functional modules to complete all or part of the functions described above. In addition, the client device provided in the above embodiment and the method embodiment of the above right belong to the same concept, and the specific implementation process is described in detail in the method embodiment.

Meanwhile, the client device provided in the above embodiment and the method embodiment for acquiring the permission belong to the same concept, and a specific implementation process thereof is detailed in the method embodiment, for example, the sending module 701 is configured to execute step S201 shown in fig. 2; a receiving module 702, configured to execute step S205 shown in fig. 2, which is not described herein again.

Referring to fig. 8, a schematic diagram of a client device 800 according to an embodiment of the present application is shown. The network device 800 may be applied in the architecture shown in fig. 1, for example, may be the client device 10 in the network architecture shown in fig. 1. For performing the operations performed by the client device in the communication method of the embodiment shown in fig. 2. As shown in fig. 8, client device 800 may include a processor 810, a memory 820 coupled to processor 810, and a transceiver 830. The processor 810 may be a Central Processing Unit (CPU), a Network Processor (NP), or a combination of a CPU and an NP. The processor may also be an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. The PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof. Processor 810 may refer to a single processor or may include multiple processors. Memory 820 may include volatile memory (volatile memory), such as random-access memory (RAM); the memory may also include a non-volatile memory (non-volatile memory), such as a read-only memory (ROM), a flash memory (flash memory), a Hard Disk Drive (HDD), or a solid-state drive (SSD); the memory may also comprise a combination of memories of the kind described above. The memory 820 may also comprise a combination of memories of the kind described above. The memory 820 may refer to one memory or may include a plurality of memories. In one embodiment, the memory 820 stores computer readable instructions, for example, the memory 820 stores program codes for implementing the functions of the transmitting module 701 and the receiving module 702. Processor 810 is configured to execute the computer readable instructions in memory 820 to cause client device 800 to perform steps S201 and S205 in fig. 2.

Referring to fig. 9, this figure is a schematic structural diagram of a server device 900 according to an embodiment of the present application, where the server device includes:

a receiving module 901, configured to receive a request message sent by a client device, where the request message carries a data node to which an operation is to be performed and an authority request parameter, where the authority request parameter is used to request an authority result, and the authority result indicates authority information for the user to perform the operation on the data node;

optionally, the receiving module 901 is further configured to receive a capability notification message sent by the client device, where the capability notification message indicates that the client device has a capability of requesting a permission result.

A generating module 902, configured to generate a response message, where the response message carries the permission result;

a sending module 903, configured to send a response message to the client device, where the response message carries the permission result.

Optionally, the operation may be an operation such as querying, modifying, or deleting, and the corresponding permission information may be an operation such as whether querying is possible, whether modifying is possible, and whether deleting is possible.

Optionally, when the operation is further a read operation, the operation may be an operation such as query (get), query configuration (get-config), incremental synchronization (sync-increment), or full synchronization (sync-full), and the application is not particularly limited.

Optionally, the sending module 903 is further configured to send a capability notification message, where the capability notification message carries an authority response capability, and the authority response capability indicates whether the server device supports the capability of returning the authority result.

Optionally, the request message is a request message of a representation layer state transition configuration protocol RESTCONF or a request message of a network configuration protocol NETCONF, and the method is supported to be used under various management protocols.

Optionally, the permission request parameter is included in a uniform resource identifier or an extensible markup language of the request message.

It should be noted that the server device provided in the foregoing embodiment and the method embodiment for acquiring the permission belong to the same concept, and specific implementation processes thereof are described in detail in the method embodiment, and all the above optional technical solutions may be adopted to form optional embodiments of the application in any combination, and are not described in detail here.

Fig. 10 is a schematic diagram of a server device 1000 provided in the present application. The server device 1000 may be applied to the architecture shown in fig. 1, and may be, for example, the server device 11 in the network architecture shown in fig. 1. For executing the operations executed by the server device in the communication method of the embodiment shown in fig. 2. As shown in fig. 10, the server device 1000 may include a processor 1010, a memory 1020 coupled to the processor 1010, and a transceiver 1030. Processor 1010 may be a Central Processing Unit (CPU), a Network Processor (NP), or a combination of a CPU and an NP. The processor may also be an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. The PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof. The processor 1010 may refer to one processor or may include a plurality of processors. Memory 1020 may include volatile memory (volatile memory), such as random-access memory (RAM); the memory may also include a non-volatile memory (non-volatile memory), such as a read-only memory (ROM), a flash memory (flash memory), a Hard Disk Drive (HDD), or a solid-state drive (SSD); the memory may also comprise a combination of memories of the kind described above. Memory 1020 may also include a combination of memories of the sort described above. The memory 1020 may refer to one memory or may include a plurality of memories. In one example, the memory 1020 stores computer readable instructions, for example, the memory 1020 stores program code for implementing the functions of the receiving module 901, the generating module 902, and the transmitting module 903. The processor 1010 is configured to execute the computer readable instructions in the memory 1020 to enable the server device 1000 to perform steps S202, S203, and S204 in fig. 2.

The embodiment of the present application also provides a computer-readable storage medium, which includes instructions, and when the computer-readable storage medium runs on a computer, the computer is caused to execute the above right acquiring method.

The terms "comprises" and "comprising," and any variations thereof, in the description and claims of this application and the above-described drawings, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional modules in the embodiments of the present application may be integrated into one module, or each module may exist alone physically, or two or more modules may be integrated into one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode.

The integrated module, if implemented in the form of a software functional module and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

Those skilled in the art will recognize that, in one or more of the examples described above, the functions described in this invention may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.

The above-described embodiments are intended to explain the objects, aspects and advantages of the present invention in further detail, and it should be understood that the above-described embodiments are merely exemplary embodiments of the present invention.

The above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for obtaining rights, comprising:

the method comprises the steps that client equipment sends a request message to server equipment, wherein the request message carries a data node and an authority request parameter, the data node and the authority request parameter are used for indicating operations to be performed by the server equipment, the authority request parameter is used for requesting an authority result, and the authority result indicates authority information for a user using the client to perform the operations on the data node;

and the client equipment receives a response message sent by the server equipment, wherein the response message carries the permission result.

2. The method of claim 1, wherein the operation is a read operation comprising a query, a query configuration, an incremental synchronization, or a full synchronization.

3. The method according to any of claims 1-2, wherein before the client device sends the request message to the server device, further comprising:

and the client equipment receives a capability notification message sent by the server equipment, wherein the capability notification message carries permission response capability, and the permission response capability indicates the capability of the server equipment for supporting the return of the permission result.

4. The method according to any of claims 1-3, wherein the request message is a request message of a representation layer state transition configuration protocol RESTCONF or a request message of a network configuration protocol NETCONF.

5. The method according to any of claims 1-4, wherein the permission request parameter is included in a uniform resource identifier or an extensible markup language of the request message.

6. A method for obtaining rights, the method comprising:

the method comprises the steps that a server-side device receives a request message sent by a client-side device, wherein the request message carries an operation which is indicated to be performed by the server-side device, a data node which the operation aims at, and an authority request parameter, the authority request parameter is used for requesting an authority result, and the authority result indicates authority information of a user for executing the operation on the data node;

and the server side equipment sends a response message to the client side equipment, wherein the response message carries the permission result.

7. The method of claim 6, wherein the operation is a read operation comprising a query, a query configuration, an incremental synchronization, or a full synchronization.

8. The method according to any one of claims 6 to 7, wherein before the server device receives the request packet, the method further comprises:

and the server side equipment sends a capability notification message to the client side equipment, wherein the capability notification message carries permission response capability, and the permission response capability indicates whether the server side equipment supports the capability of returning the permission result.

9. The method according to any one of claims 6 to 8, wherein the request message is a request message of a representation layer state transition configuration protocol RESTCONF or a request message of a network configuration protocol NETCONF.

10. The method according to any of claims 6-9, wherein the permission request parameter is included in a uniform resource identifier or extensible markup language of the request message.

11. A client device, comprising:

a memory for storing a plurality of data to be transmitted,

sending a request message to a server device, wherein the request message carries a data node and an authority request parameter which indicate the operation to be performed by the server device, the authority request parameter is used for requesting an authority result, and the authority result indicates authority information for a user using the client device to perform the operation on the data node;

12. The client device of claim 11, wherein the operation is a read operation comprising a query, a query configuration, an incremental synchronization, or a full synchronization.

13. The client device of any of claims 11-12, wherein prior to sending the request message to the server device, the processor is configured to execute the computer-readable instructions in the memory to cause the client device to:

and receiving a capability notification message sent by the server side equipment, wherein the capability notification message carries the permission response capability, and the permission response capability indicates whether the server side equipment supports the capability of returning the permission result.

14. The client device according to any one of claims 11 to 13, wherein the request message is a request message of a rest conf protocol or a request message of a NETCONF protocol.

15. A client device according to any of claims 11-14, wherein the permission request parameter is included in a uniform resource identifier or an extensible markup language of the request message.

16. A server-side device, comprising:

a memory for storing a plurality of data to be transmitted,

a processor coupled to the memory, the processor configured to execute the computer-readable instructions in the memory such that the server device performs the following:

receiving a request message sent by client equipment, wherein the request message carries a data node and an authority request parameter aiming at an operation to be performed by the server equipment, the authority request parameter is used for requesting an authority result, and the authority result indicates authority information for a user using the client equipment to perform the operation on the data node;

and sending a response message to the client equipment, wherein the response message carries the permission result.

17. The server-side device of claim 16, wherein the operation is a read operation comprising a query, a query configuration, an incremental synchronization, or a full synchronization.

18. The server-side device of any one of claims 16-17, wherein before the server-side device receives the request message, the processor is configured to execute the computer-readable instructions in the memory to cause the server-side device to:

19. The server-side device according to any one of claims 16 to 18, wherein the request message is a request message of a representation layer state transition configuration protocol RESTCONF or a request message of a network configuration protocol NETCONF.

20. The server-side device of any one of claims 16 to 19, wherein the permission request parameter is included in a uniform resource identifier or an extensible markup language of the request message.

21. A network system, characterized in that the network system comprises a client device and a server device, the client device is any one of the client devices claimed in claims 11 to 15, and the server device is any one of the server devices claimed in claims 16 to 20.