Moderation of shared data objects

Methods, system, and computer storage media are provided for moderating actions performed on shared data objects. Rule enforcement logic is received for an application that is associated with one or more data objects shared between various clients. The rule enforcement logic is stored at a data server that also stores data associated with data objects. A moderator, also stored on the data server, is used to enforce the rule enforcement logic corresponding to the application when a client attempts to perform an action to a data object associated with the application.

BACKGROUND

With improved connectivity and access of computers and other devices to various networks, it has become commonplace for different programs, or clients, to share access to the same information, such as data objects. Sharing of data objects enables the sharing of information in real-time across multiple, disparate clients, such as machines that are running multiple pieces of technology. With the sharing of data object comes the inevitable issue of access to the data objects, including who is allowed to modify the data and what modifications are allowed. In many systems, logic to enforce various rules is stored by each client, which leaves the system vulnerable to a rogue client bypassing checks and invalidating or tampering with the data. Further, the client itself could monitor its own shared data, but this is likely to prove to be prohibitively expensive for that client. Additionally, it may be challenging for a developer to accurately revert a disallowed modification once it has already been propagated to all clients that share access to that particular data object since the old values may no longer be saved in the system.

SUMMARY

Embodiments of the present invention relate to the use of a server side moderator that enforces logic supplied by the developer of an application to determine what actions may be taken to data objects associated with that application. Instead of being stored on the client side, the rule enforcement logic may now be stored on the server along with data that comprises the shared data objects. When a client attempts to modify a data object, for instance, that modification is first approved or rejected by a moderator before the change is saved and propagated to other clients that share the same data object. If the client is not allowed to make that particular modification, the modification is not made. In this instance, other clients that share that data object may not even know that the modification was attempted. If the client is allowed to make that particular modification, the modification is allowed.

DETAILED DESCRIPTION

Embodiments of the present invention are directed to methods and systems for providing moderation of attempted actions taken to shared data objects. At the data server where data and rule enforcement logic is stored, data is first partitioned by application and then by application instance. Here, a moderator is at the application level on the server. When an instance of the moderator is present within an application, all incoming changes for all application instances are first passed to the moderator, which can either accept or reject the change. If the change is accepted, the server will continue regular execution by committing the change and sending it out to all registered clients. If the change is rejected, the server sends an error message to the client that attempted to make the change, and the change is automatically reverted using built in client side logic.

Accordingly, in one aspect, an embodiment of the present invention is directed to one or more computer storage media storing computer-useable instructions that, when used by one or more computing devices, cause the one or more computing devices to perform a method of moderating actions performed on shared data objects. The method includes receiving rule enforcement logic for an application. The application is associated with one or more application instances, each of which contains one or more data objects that are shared between two or more clients. Further, the method includes storing the rule enforcement logic at a data server that stores data associated with a plurality of data objects and rule enforcement logic corresponding to a plurality of applications associated with the plurality of data objects. Additionally, the method includes utilizing a moderator stored on the data server to enforce the rule enforcement logic associated with the application when one of the two or more clients attempts to perform an action to one of the one or more associated data objects. The action comprises one or more of opening the data object, deleting the data object, or modifying the data that comprises the data object.

In another embodiment, an aspect of the invention is directed to one or more computer storage media storing computer-useable instructions that, when used by one or more computing devices, cause the one or more computing devices to perform a method of moderating actions performed on shared data objects. The method includes receiving a request from a client to perform an action to a data object whose data is stored on a data server, determining whether the data server has stored rule enforcement logic that corresponds to an application associated with the data object. If the data server has stored the rule enforcement logic corresponding to the application associated with the data object, the method further includes utilizing the rule enforcement logic to determine whether the client is allowed to perform the requested action to the data object, performing the requested action to the data object if it is determined that the client is allowed to perform the requested action to the data object, and not performing the requested action to the data object and communicating an error message to the client if it is determined that the client is not allowed to perform the requested action to the data object. Further, if the data server does not have stored the rule enforcement logic corresponding to the application associated with the data object, the method includes performing the requested action to the data object.

A further embodiment of the present invention is directed to a shared data system including one or more computing devices having one or more processors and one or more computer storage media. The shared data system includes a server that comprises a data store that stores data associated with a plurality of data objects and rule enforcement logic corresponding to a plurality of applications associated with at least a portion of the plurality of data objects. The rule enforcement logic is developed by and received from a developer of a respective application. The server further includes a moderator that enforces the rule enforcement logic for the plurality of applications associated with the at least the portion of the plurality of data objects such that when a client attempts to perform an action to a data object, the moderator determines whether the action is allowed based on the corresponding rule enforcement logic for the application associated with that particular data object. If the moderator determines that the action is allowed, the server allows the action, but if the moderator determines that the action is not allowed, the server does not allow the action and communicates an error message to the client indicating that the action is not allowed.

Referring now toFIG. 2, a block diagram is provided illustrating an exemplary computing system environment200suitable for use in implementing embodiments of the present invention. It will be understood and appreciated by those of ordinary skill in the art that the computing system environment200shown inFIG. 2is merely an example of one suitable computing system environment and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the present invention. Neither should the computing system environment200be interpreted as having any dependency or requirement related to any single module/component or combination of modules/components illustrated therein. Among other components not shown, the system200includes client devices202and204, a shared data server208, a data store210, an application “A” moderator212, and an application “B” moderator214, all in communication with one another through a network206. The network206may include, without limitation, one or more local area networks (LANs) and/or wide area networks (WANs). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. Accordingly, the network206is not further described herein.

In some embodiments, one or more of the illustrated components/modules may be implemented as stand-alone applications. In other embodiments, one or more of the illustrated components/modules may be integrated directly into other components. It will be understood by those of ordinary skill in the art that the components/modules illustrated inFIG. 2are exemplary in nature and in number and should not be construed as limiting. Any number of components/modules may be employed to achieve the desired functionality within the scope of embodiments hereof. Further, components/modules may be located on any number of servers, client devices, or the like. By way of example only, the shared data server208might reside on a larger server, cluster of servers, or a computing device remote from one or more of the remaining components. Further, application “A” moderator212and application “B” moderator214may reside directly on the shared data server208, although shown here as separate components. For instance, in one embodiment, the moderators are logic that is simply stored on the shared data server208.

Data objects, as used herein, refer to any entity that is able to be manipulated by commands of one or more programming languages, such as value, variable, function, or data structure. In software development, objects are used to implement abstract data structures by bringing together the data components with the procedures that manipulate them. An object stores its state in fields, or variables in some programming languages, and exposes its behavior through methods, or functions in some programming languages. Many instances of a particular object may exist, and thus these instances belong to a particular class, which is the blueprint from which individual objects are created. Once created, objects may be updated or modified by a number of clients. In one embodiment, a client attempts to perform an action (e.g., open, close, delete, modify) on a data object that has been opened using a particular application. As used herein, an application is computer software designed to assist a user to perform tasks, and as mentioned, may be used to open and modify various data objects, including documents.

With continued reference toFIG. 2, each of client devices202and204, data server208, and moderators212and214may be any type of computing device, such as computing device100described with reference toFIG. 1, for example. The components may communicate with each other via a network206, which may include, without limitation, one or more local area networks (LANs) and/or wide area networks (WANs). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. It should be understood that any number of client devices, servers, and data stores may be employed within the system200within the scope of the present invention. Each may comprise a single device or multiple devices cooperating in a distributed environment. For instance, the shared data server208may comprise multiple devices arranged in a distributed environment that collectively provide the functionality of the shared data server208described herein. Additionally, other components not shown may also be included within the system200, while components shown inFIG. 2may be omitted in some embodiments.

The client devices202and204may be any type of computing device owned and/or operated by a client that can access the network206. For instance, each of the client devices202and204may be a desktop computer, a laptop computer, a tablet computer, a mobile device, or any other device having network access. Generally, a client may employ the client devices202and204to, among other things, attempt to open, delete, modify, etc., a data object stored on the shared data server208using an application. In one instance, a client utilizes the client device202, for example, to attempt to access and modify a data object, by way of an application, stored on the shared data server208. As will be described herein, logic on the server may dictate whether this client is even allowed to open that data object, let alone make any modifications to it that are then stored on the server and accessible to other clients.

The shared data server208comprises various components, including a receiving component216, a storing component218, an error response component220, and an enforcement component222. Generally, the receiving component216is configured to receive rule enforcement logic from a developer of an application, typically referred to as an originating client. Rule enforcement logic is logic that, in one embodiment, is provided by the developer of an application that may be used in conjunction with data objects. Instead of being stored by each developer individually, the rule enforcement logic may be stored by the system, such as on the shared data server208or the data store210. Alternatively, the rule enforcement logic is stored on a separate moderator, as shown inFIG. 2.

There may be some issues with safety, such as tampering with the logic or data, if the logic is stored or if it exists within the client code. Storing of the logic with the client code would leave the logic to be vulnerable to a rogue client bypassing these checks and invalidating or tampering with the data. Another alternative includes a developer writing custom logic on its own server, which would serve to monitor the shared data and revert invalid changes, but in many cases this is prohibitively expensive to keep this in sync. It would also be very challenging for the developer to accurately revert an invalid change once it has already propagated the changes to all clients, as the old value would no longer be in the system. Yet another alternative would be if the developer could discard using the existing shared data service and instead write its own fully customized service. While possible, the developer would be ultimately responsible for all the challenges of writing an asynchronous shared data service, including keeping the data synchronized across all clients in real time, and making the system scale to many users. As such, storing the rule enforcement logic on the shared data server has many benefits, including securing of the logic and data and less expensive in terms of keeping the changes in sync. The receiving component216is also configured to receive actions that have been attempted on a particular application or data object. For example, client device202may have attempted to modify data in a particular application that has corresponding rule enforcement logic. The receiving component216receives an indication of this attempted modification and enlists the appropriate moderator to determine whether that modification will be accepted or rejected.

The storing component218is configured to determine how and where to store rule enforcement logic received from a particular developer. In embodiments, the rule enforcement logic is stored directly in the shared data server208, but in another embodiment, it may be stored on a separate data store, such as data store210that is operably connected to the shared data server208. The data store210, in one embodiment, stores data associated with data objects and rule enforcement logic corresponding to a plurality of applications associated with the data objects.

The error response component220is configured to produce an error message and communicate it to a client who has attempted an action to a data object or application, but whose attempted action has been rejected by enforcement of the rule enforcement logic for that particular application. For example, if a first client utilizing client device202is attempting to open a particular data object using application “A,” application “A” moderator212utilizes the corresponding rule enforcement logic to determine whether the open request is approved or rejected. If rejected, the error response component220may communicate an error request to the first client indicating that the data object cannot be opened according to the rule enforcement logic provided by the developer of the application used in conjunction with the data object.

The enforcement component222is configured to be in direct communication with the moderators to enforce rule enforcement logic. In one embodiment, the enforcement component222is responsible for determining whether a particular application has rule enforcement logic associated with it. In some instances, not all applications have corresponding rule enforcement logic.

The application moderators212and214are illustrated as separate components from the shared data server208. While these moderators are illustrated as separate components inFIG. 2, in some embodiments, the client moderators212and214are actually integrated into the shared data server208. For instance, the client moderators212and214may comprise rule enforcement logic that is stored on the shared data server208, and structurally may not be a separate component. There are many alternatives as far as the structure of the system.FIG. 2is illustrated for exemplary purposes only. Generally, moderators212and214enforce rule enforcement logic for applications such that when a client attempts to perform an action to a data object associated with the application, the moderator determines whether the action is allowed based on the corresponding rule enforcement logic for the application associated with that particular data object.

Generally, application “A” moderator212is utilized to enforce logic provided by, for example, the developer of application “A”. The developer of application “A” may have the ability to “preview” incoming changes to shared resources (e.g., application “A”) and then approve or reject these changes before the changes are propagated to the rest of the system based on application-specific logic. This system supports reverting the local change on the client who attempted to make the change if the moderator has rejected it based on the corresponding rule enforcement logic. As such, many different applications/data objects can store shared data on the same server, and each application can have its own, unique, version of rule enforcement logic. As the rule enforcement logic is unique for each application, the moderators act on an application level on the server. This is shown inFIG. 3discussed below. When rule enforcement logic is stored on the shared data server (e.g., data store210, moderators212or214) for a particular application, all incoming changes for all application instances are first passed to the moderator, which may either accept or reject the change. If the change is accepted, the server will continue regular execution, commit the change, and communicate it out to all registered clients. If the change is rejected, however, the shared data server208may, in one embodiment, communicate an error message to the client that attempted to perform the action to the data object, indicating that the action is not allowed. The change to the data object may then be automatically reverted using built-in client side logic.

The moderators are provided to developers of applications and data objects, as they expose “preview” events for all types of incoming changes, or attempted actions, as previously mentioned. These actions may include creation, deletion, opening, closing, modifying in any way, etc. These actions can either be sent for all resources in the shared system, or for a limited set in which the application is interested in. The developer may then attach its own custom logic to each event to decide when to approve or reject a given change. In one embodiment, when one of these events fires, the developer is provided with all of the pertinent information about the incoming change, such as what the action is and who is attempting to execute the change. Additionally, the moderator has a full representation of the shared data as it is seen by the clients. The developer is responsible for writing any logic it desires that the moderator execute. Once complete, the developer registers its custom moderator (e.g., rule enforcement logic) with the shared data service, which will then execute the rule enforcement logic whenever there is a change to the corresponding application/data object.

Referring now toFIG. 3, a block level architecture diagram300is illustrated of a shared data server. A shared data server302may be similar or the same as the shared data server208described in reference toFIG. 2. For a particular data object or application, such as application XYZ304, multiple instances of that application may exist. Here, each application instance, including application instance1306, application instance2308, and application instance3310represent three instances of application XYZ304. The moderator for application XYZ312resides at the application level and communicates with all active instances of the application.

FIG. 4illustrates a flow diagram showing a method400for moderating shared data objects, in accordance with an embodiment of the present invention. Various steps may be performed by either a client, the server, or the moderator. The legend414provides an indication as to which steps are performed by which component. Initially at step402, object “X” is opened by a client. At step404, it is determined by the server as to whether a moderator (e.g., rule enforcement logic) exists for application “A.” If a moderator does not exist for application “A,” the typical response by the server is to go ahead and allow the client to open object “X,” shown at step406. At step408, object “X” is opened on the client side. If, however, a moderator (e.g., rule enforcement logic) does exist for that application, the rule enforcement logic is used to determine whether the client is allowed to open object “X,” shown at step410. This decision is made by the moderator. If the client is not allowed to open object “X,” the object is not opened at step412.

Turning toFIG. 5, a flow diagram showing a method500for moderating actions performed on shared data objects is depicted, in accordance with an embodiment of the present invention. Initially at step510, rule enforcement logic is received for an application. In one embodiment, the rule enforcement logic is received from a developer of the application, also termed an originating client. The application is associated with one or more data objects that are shared between two or more clients. For instance, the application may be used to open and make modifications to a data object. Applications may also be used as a way to separate data and rule enforcement logic between different developer's code to avoid naming collisions, etc. Examples may include a game of chess, a chat application, or the like. The clients, as used herein, may include, for exemplary purposes only, a computer, a web browser, a mobile device, or a gaming system. Other types of clients may also be used to carry out embodiments of the present invention.

At step512, the rule enforcement logic is stored at a data server that stores data associated with a plurality of data objects. The data server also stores rule enforcement logic corresponding to a plurality of applications associated with the plurality of data objects. For instance, a single application may be useable with one or more data objects. It should be noted that the rule enforcement logic is not stored at a client site along with code corresponding to the data object or application. Instead, here, it is stored at the data server where data that comprises data objects is also stored. At step514, a moderator is used to enforce the rule enforcement logic (e.g., whether to approve or reject an attempted action) when a client attempts to perform an action to a data object associated with the application. The action may comprise, for exemplary purposes only, opening the object, closing the object, deleting the object, or making any modifications to the data that comprises the object. For instance, if the action is modifying the data of the data object, this data server (e.g., the moderator using the rule enforcement logic) may determine and enforce bounds for data values. If a client attempts to modify a numerical value higher than a high threshold defined in the rule enforcement logic, this modification may not be allowed.

If the moderator determines that the client is allowed to modify the data object based on the rule enforcement logic, the data is modified accordingly and changes to the data object may be sent out to other clients who share access to that data object. If, however, the moderator determines that the client is not allowed to modify the data of the data object based on the rule enforcement logic associated with the application, any attempted modifications to the data object are reverted. Further, the attempted modifications are discarded and not saved to the data server such that the client that attempted the modification maintains an accurate representation of the data as it is stored on the server. In one embodiment, when a client attempts to perform an action to the data object, access information is communicated to the developer of the application associated with the data object. This access information may include, for example, details regarding the attempted action (e.g., what the action was, details of the action) and/or the identity of the client that attempted to perform the action to the data object.

Referring toFIG. 6, a flow diagram showing a method600for moderating actions performed on shared data objects is shown, in accordance with an embodiment of the present invention. At step610, a request is received from a client to perform an action to a data object whose data is stored on a data server. This action may include, for exemplary purposed only, opening the data object, deleting the data object, or modifying the data that comprises the data object. It is determined at step612whether the data server has stored rule enforcement logic that corresponds to an application associated with the data object. Rule enforcement logic is stored on the data server in correspondence to a particular application having associated data objects whose data is also stored on the data server. If it does not have the rule enforcement logic stored thereon, the requested action is performed to the data object at step614. If the server does have the rule enforcement logic stored thereon, it is next determined whether the client is allowed to perform the requested action to the data object, shown at step616. If it is, the requested action is performed to the data object at step614. If it is not, the requested action is not performed to the data object, shown at step618. Additionally, an error message is communicated to the client. When at attempted action is made to a data object, access information regarding that attempted action may be communicated to the developer of the application, including details regarding the requested action and/or an identity of the client attempting to perform the requested action to the data object.