This application is based on and claims priority under 35 USC 119 from Japanese Patent Application No. 2014-036503 filed Feb. 27, 2014 and Japanese Patent Application No. 2014-036504 filed Feb. 27, 2014.
(i) Technical Field
The present invention relates to an information processing system, an information processing method, and a non-transitory computer readable medium.
(ii) Related Art
Servers managing objects may process (for example, generate, acquire, change, or delete) the objects depending on authorities of clients, which submit requests for the processing. Since the objects managed by the servers may be subjected to, for example, the generation, the change, or the deletion, fixing the authorities to the clients independently of the objects may make difficult to flexibly process the objects in accordance with the authorities of the clients. In addition, allowing the content of content to be provided to be varied depending on the authorities of the clients may advance the development of systems and may improve the availability of the systems.
According to an aspect of the invention, there is provided an information processing system including a managing unit that manages objects for each of which at least one of a parent and a child is defined, an element name and an element value of an element composing content being associated with at least part of the objects in the managing unit; a receiving unit that receives a request for a process including specification of an authorized object with which authority information is associated; a setting unit that sets a target object on the basis of the authorized object and, if the element name specified in the request is not associated with the target object, repeats a process of setting a parent object of the target object as a new target object until a predetermined condition is met; and a responding unit that, if the element name specified in the request is associated with the target object set by the setting unit, returns the element value associated with the target object as a response to the request.
Exemplary embodiments of the present invention will be described in detail based on the following figures, wherein:
Exemplary embodiments of the present invention will herein be described with reference to the attached drawings.
As illustrated in
The controller 10A includes a central processing unit (CPU). The controller 10A executes a variety of arithmetic processing and controls each component in the information managing apparatus 10 on the basis of programs stored in the memory 10B.
The memory 10B stores control programs, such as an operating system (OS) of the information managing apparatus 10, and data and is also used as a working memory of the controller 10A. The programs may be supplied to the information managing apparatus 10 in a state in which the programs are stored in an information storage medium, such as an optical disk, a magnetic disk, a magnetic tape, a magneto-optical disk, or a flash memory, or may be supplied to the information managing apparatus 10 over a data communication network, such as the Internet.
The communication unit 10C includes, for example, a network interface card (NIC) and is connected to the network 2 via the NIC to communicate with the one or more user terminals 5 connected to the network 2.
In the present exemplary embodiment, the information managing apparatus 10 manages prototype-based objects. The prototype-based objects are objects each having only one parent object (prototype), except for a root object existing alone in a collection of the prototype-based objects. The root object does not have its prototype. When an object A is the prototype of an object B, the object B is also referred to as an artifact of the object A. The entire collection of the prototype-based objects is represented by a tree structure using the prototype relationship between the objects. Reconnecting the prototypes allows the tree structure to be modified as long as the reconnection does not destroy the tree structure composed of the objects. The objects managed by the information managing apparatus 10 may have attributes and attribute values. In a REpresentational State Transfer (REST) architecture style, each object may be called a resource and each value may be called a representation. The object having the value may represent authority information called access token. The objects may include objects representing only simple identities simply composed of object identifiers and the prototypes, objects representing pieces of data having arbitrary content-type values, and objects representing entities, such as the access token, which is a credential certifying the access qualification; resource owners, which are the owners of the objects; or applications (clients), which access the objects on the basis of the approval of the resource owners. These objects are included in one tree structure.
In the present exemplary embodiment, the information managing apparatus 10 performs addition or update of the object to be managed, reading or deletion of information, and so on in accordance with a request received from the user terminal 5. In addition, the information managing apparatus 10 associates identification information for identifying a function with an authorized object called the access token to process the request received from the user terminal 5 with the function associated with the authorized object received from the user terminal 5 along with the request. Exemplary functions with which the information managing apparatus 10 is provided in order to realize the above processing will be described in detail below.
Exemplary functions of the information managing apparatus 10 will now be described with reference to a functional block diagram of the information managing apparatus 10 illustrated in
The function of each component provided in the information managing apparatus 10 may be realized by the controller 10A in the information managing apparatus 10, which reads out the programs stored in the memory 10B or the computer-readable information storage medium to execute the programs that are read out. The programs may be supplied to the information managing apparatus 10 via an information storage medium, such as an optical disk, a magnetic disk, a magnetic tape, a magneto-optical disk, or a flash memory, or may be supplied to the information managing apparatus 10 over a data communication network, such as the Internet. The function of each component in the information managing apparatus 10 will now be described in detail.
The object information managing unit 11 manages information about the prototype-based objects and information about data objects. The prototype-based objects include the authorized objects called the access token, with which the authority information is associated. The prototype-based objects are mutable objects and are typically identified with identifiers (IDs) that are generated at random. The data objects are immutable objects and are typically identified with IDs that are calculated as hash values of the corresponding pieces of data. The data objects include, for example, source codes used for generating function objects and function data objects including the identification information about the function objects generated from the source codes and so on. Exemplary data structures of the prototype-based object and the data object will now be described with reference to
Exemplary management tables used for managing the prototype-based object and the data object having the data structures illustrated in
The request receiving unit 12 receives a request concerning the processing of the object managed by the object information managing unit 11 from the user terminal 5. For example, the request receiving unit 12 may receive the request in a HyperText Transfer Protocol (HTTP) format from the user terminal 5.
The authority information acquiring unit 13 acquires information about the access token (authorized object) concerning the request received by the request receiving unit 12. For example, the authority information acquiring unit 13 may acquire the information about the access token from an Authorization field in the HTTP request or may acquire the information about the access token from any cookie including the information about the access token.
The verifying unit 14 verifies whether the information about the access token (authorized object) acquired by the authority information acquiring unit 13 is valid. A specific example of the verification process in the verifying unit 14 will now be described.
First, the verifying unit 14 determines whether the ID of the access token acquired by the authority information acquiring unit 13 is included in the prototype-based object management table managed by the object information managing unit 11 (a first condition). If the ID of the access token is not included in the prototype-based object management table, the verifying unit 14 determines that the verification failed.
If the first condition is met, the verifying unit 14 determines whether the data format (type) of the access token is a certain type (that is, application/json) (a second condition). If the data format (type) of the access token is not the certain type, the verifying unit 14 determines that the verification failed.
If the second condition is met, the verifying unit 14 acquires the values of the access token (the values of “owner”, “client”, and “scope”) to determine whether the respective values of “owner”, “client”, and “scope” are the data managed by the object information managing unit 11 (a third condition). If any of the values is not the data managed by the object information managing unit 11, the verifying unit 14 determines that the verification failed.
If the third condition is met, the verifying unit 14 acquires the information about the prototype of the access token from the object information managing unit 11 to determine whether the prototype of the access token coincides with the owner of the access token or is included in a prototype chain of the owner (a path in which ancestors of the owner are connected sequentially from the parent of the owner) (a fourth condition). If the prototype of the access token does not coincide with the owner of the access token and is not included in the prototype chain, the verifying unit 14 determines that the verification failed.
If the fourth condition is met, the verifying unit 14 determines whether the function object is allocated to the information about the scope of the access token (a fifth condition). If no function object is allocated to the scope, the verifying unit 14 determines that the verification failed. If the function object is allocated to the scope, the verifying unit 14 determines that the verification succeeded. Whether the function object is allocated to the scope may be based on whether the function object is acquired by the function object acquiring unit 15 on the basis of the information about the scope.
The function object acquiring unit 15 acquires the information about the function object associated with the scope from the object information managing unit 11 on the basis of the information about the scope of the access token. For example, the function object acquiring unit 15 searches the data object management table managed by the object information managing unit 11 for the corresponding record on the basis of the information about the scope of the access token (the ID of the data object). The function object acquiring unit 15 refers to the func attribute of the record that is searched for and, if a value is stored in the func attribute, the function object acquiring unit 15 acquires the value of the func attribute as the identification information about the function object. If no value is stored in the func attribute of the record that is searched for, the function object acquiring unit 15 requests the function object generating unit 16 to generate (evaluate) the function object based on the source code stored in the content attribute.
The function object generating unit 16 determines whether the source code concerning the request from the function object generating unit 16 is capable of being evaluated as the function. If the source code is not capable of being evaluated as the function, the function object generating unit 16 returns an error to the function object acquiring unit 15. If the source code is capable of being evaluated as the function, the function object generating unit 16 returns the identification information of the function object generated on the basis of the source code to the function object acquiring unit 15.
If the error is returned from the function object generating unit 16, the function object acquiring unit 15 indicates that the function object is not allocated to the verifying unit 14. If the identification information about the function object is returned from the function object generating unit 16, the function object acquiring unit 15 stores the identification information about the function object as the value of the func attribute of the corresponding record and indicates the identification information about the function object allocated to the scope to the verifying unit 14.
The request processing unit 17 controls the processing of the request received by the request receiving unit 12 on the basis of the result of the verification of the access token (authorized object) acquired by the authority information acquiring unit 13 for the request received by the request receiving unit 12, which is indicated from the verifying unit 14, and the function object acquired by the function object acquiring unit 15 for the received access token. For example, if the result of the verification of the access token concerning the request received by the request receiving unit 12 is failure, the request processing unit 17 may not accept the processing concerning the request and may supply an error to the processed data providing unit 18. If the result of the verification of the access token concerning the request received by the request receiving unit 12 is success, the request processing unit 17 processes the request received by the request receiving unit 12 on the basis of the function object acquired by the function object acquiring unit 15 for the access token received for the request and supplies the result of the processing to the processed data providing unit 18.
The processed data providing unit 18 provides the result of the processing in the request processing unit 17 to the user terminal 5, which has submitted the request.
Exemplary processes executed in the information processing system S will now be described in detail with reference to flowcharts illustrated in
Referring to
In Step S103, the information managing apparatus 10 receives a request to generate an access token T including an owner o, a client c, and a scope f (the identification information about the object f) using the access token t from, for example, the user terminal 5. In Step S104, the information managing apparatus 10 generates the access token T. In Step S105, the information managing apparatus 10 provides the information about the access token T generated in Step S104 (the ID of the access token T) to, for example, user terminal 5. Then, the process in
Referring to
In Step S203, the information managing apparatus 10 executes a verification process based on the access token acquired in Step S202. The verification process based on the access token will be described in detail below with reference to a flowchart illustrated in
If the ID of the access token to be verified exists in the IDs managed by the object information managing unit 11 (YES in Step S301), in Step S302, the information managing apparatus 10 refers to the data about the access token using the ID of the access token as a key to determine whether the data format of the access token is valid. For example, the information managing apparatus 10 may determine that the data format of the access token is valid if the type attribute set in the access token is application/json and otherwise may determine that the data format of the access token is not valid. If the data format of the access token is valid (YES in Step S302), the process goes to Step S303. If the data format of the access token is not valid (NO in Step S302), in Step S312, the information managing apparatus 10 determines that the verification failed. Then, the process returns to the process illustrated in
If the data format of the access token is valid (YES in Step S302), in Step S303, the information managing apparatus 10 acquires the values (IDs) of the owner, the client, and the scope specified for the access token. In Step S304, the information managing apparatus 10 determines whether the object ID specified by the owner, the client, and the scope exists in the IDs managed by the object information managing unit 11. For example, the information managing apparatus 10 may perform the above determination based on whether the object ID specified by the owner, the client, and the scope is included in either of the prototype-based object management table and the data object management table. If the object ID of the owner, the client, and the scope specified for the access token is included in the IDs managed by the object information managing unit 11 (YES in Step S304), the process goes to Step S305. If the object ID of the owner, the client, and the scope specified for the access token is not included in the IDs managed by the object information managing unit 11 (NO in Step S304), in Step S312, the information managing apparatus 10 determines that the verification failed. Then, the process returns to the process illustrated in
If the object ID of the owner, the client, and the scope specified for the access token is included in the IDs managed by the object information managing unit 11 (YES in Step S304), in Step S305, the information managing apparatus 10 acquires the information about the prototype (the object ID of the parent object) of the access token. In Step S306, the information managing apparatus 10 determines whether the prototype object of the access token coincides with the owner specified for the access token or is included in the prototype chain of the owner (the path in which ancestor objects of the owner are sequentially connected). If the information managing apparatus 10 determines that the prototype object of the access token is included in the prototype chain of the owner (YES in Step S306), the process goes to Step S307. If the information managing apparatus 10 determines that the prototype object of the access token is not included in the prototype chain of the owner (NO in Step S306), in Step S312, the information managing apparatus 10 determines that the verification failed. Then, the process returns to the process illustrated in
If the prototype object of the access token coincides with the owner specified for the access token or is included in the prototype chain of the owner (YES in Step S306), in Step S307, the information managing apparatus 10 refers to the data about the object ID of the scope specified for the access token. For example, the information managing apparatus 10 may refer to the information about the records stored in the data object management table using the object ID of the scope as a key.
In Step S308, the information managing apparatus 10 determines whether the function object is allocated to the data about the scope referred to in Step S307. For example, the information managing apparatus 10 may perform the above determination based on whether the identification information is stored in the func attribute in the data about the scope. If the function object is allocated to the data about the scope (YES in Step S308), in Step S309, the information managing apparatus 10 determines that the verification succeeded. Then, the process returns to the process illustrated in
The verification process based on the access token is performed in the above manner. The description returns to the flowchart in
Referring back to
In Step S206, the information managing apparatus 10 processes the request received in Step S201 on the basis of the function object associated with the access token acquired in Step S205. In Step S207, the information managing apparatus 10 provides the processed data resulting from the processing in Step S206 to the user terminal 5, which has submitted the request, as a response to the request. Then, the process in
If the result of the verification of the access token is failure (NO in Step S204), in Step S208, the information managing apparatus 10 returns an error to the user terminal 5, which has submitted the request. Then, the process in
According to the information managing apparatus 10 described above, it is possible to associate arbitrary server-side processing with the access token. Accordingly, varying the value of the scope associated with the access token for one end point allows the processing to be executed to be switched.
An exemplary process for a request executed in the information managing apparatus 10 will be described with reference to a flowchart illustrated in
An exemplary process of reading out data concerning the request from the prototype-based object to respond to the request will now be described with reference to the flowchart illustrated in
Referring to
If uri acquired in Step S401 is not in the format of the object ID (NO in Step S402), in Step S406, the information managing apparatus 10 determines that the attribute name is specified for uri and sets the object specified by the information about the client of the access token concerning the request received from the user terminal 5 as a target object.
In Step S407, the information managing apparatus 10 determines whether the attribute specified with uri is included in the data added to the target object. If the attribute specified with uri is included in the data added to the target object (YES in Step S407), in Step S408, the information managing apparatus 10 returns the data added to the target object as the attribute value of the attribute concerning the request. Then, the process in
If the attribute specified with uri is not included in the data added to the target object (NO in Step S407), in Step S409, the information managing apparatus 10 determines whether the parent (that is, prototype) object of the current target object exists. If the parent (that is, prototype) object of the current target object exists (YES in Step S409), in Step S410, the information managing apparatus 10 sets the parent of the current target object as a new target object. Then, the process goes back to Step S407. If the parent (that is, prototype) object of the current target object does not exist (NO in Step S409), in Step S405, the information managing apparatus 10 determines that the corresponding data does not exist and notifies the user terminal 5 of the error. Then, the process in
While the invention is described in terms of some specific exemplary examples and embodiments, it will be clear that this invention is not limited to the specific examples of the structure and the configuration and the example of how to store the data and that many changes and modified exemplary embodiments will be obvious to those skilled in the art without departing from the true spirit and scope of the invention. For example, the data structure and the processing order may be modified. For example, although the example in which the identification information about the function data object is specified for the scope of the access token is described in the above exemplary embodiments, the function (command) itself may be fixed to the scope.
The foregoing description of the exemplary embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously, many modifications and variations will be apparent to practitioners skilled in the art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, thereby enabling others skilled in the art to understand the invention for various embodiments and with the various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents.
Number | Date | Country | Kind |
---|---|---|---|
2014-036503 | Feb 2014 | JP | national |
2014-036504 | Feb 2014 | JP | national |