Access Control

The prototype from Listings 5 through 7 allows listing, saving, and deleting posts, but without any access controls. So far, any client can edit any post. Listing 8 prepares the sample application for access control by removing Meteor packages and adding others. Line 1 forces the sample application to assign permission explicitly to save and delete database contents after uninstalling the insecure package. Line 2 ensures that data collections need to be explicitly released for reading after removing the autopublish package. Lines 3 and 4 install the accounts-password and accounts-ui packages to add user management. Figure 7 shows the process of signing in to the application.

Figure 7: Signing into the sample application.

Reading Permitted

Listing 9 is the publish() method called on the web server to allow the browser to read all objects from the Articles data collection. The expression return Articles.find({public:True}) would only allow line 2 to provide access to a subset of the object with a property of Public=True. The code is stored in the server.js file in the same directory.

Conversely, the expression Meteor.subscribe("articles"); would allow the browser to read the data published in Listing 9. You need to add these lines to the client/client.js file. The JavaScript code in Listing 10 saves and deletes objects from the Articles data collection, in line with the access controls described. These lines of code extend the model.js file. Lines 2 to 5 of the allow() method describes the event handling for calling remove(). Only if the callback function returns a value of True – that is, only if the current user is the creator of the article  – is the user allowed to delete the post.

Please Log In

The methods() method in Listing 10 (lines 7-21) initializes the upsert function on the web server. Listing 11 calls it as a stored procedure or remote procedure in line 4. The function takes an identifier and the title and text of the post. If the user is not logged in, lines 9 and 10 in Listing 10 interrupt the function call with an error.

Line 13 then immediately constructs the object to be stored. The owner field takes the identity of the user from user management. Because, after uninstalling the insecure package, a direct call to the upsert() method is no longer permitted, existing posts are updated in line 15 using update() or added in line 18 by insert().

The update call is tied to two conditions in line 15: _id: id restricts the update to the current post and owner: this.userId restricts it to the author of the post. In the second call parameter, the $set identifier causes the object to be completely replaced. If there is no update, the return value of 0 in line 15 causes Meteor to throw an error.

The JavaScript code in Listing 11 takes the upsert() from Listing 10 off the substitute's bench [9]. A call to the Events method replaces the call in Listing 7, lines 18 to 28. The callback function for the save event (lines 2-9) uses call() in line 4 to call the upsert() function on the web server. Its first parameter call takes the function name; the other parameters are passed to the server-side call function, except for the last one.

The last parameter contains a callback function that Meteor executes in case of error. It displays an error message in the editor in line 5, then switches to the editor view in line 6. A value of 1 in lines 8 and 12 tells nav() to use the list view.