The Allow & Deny Security Challenge
Guides, tutorials, and articles are all fine, but sometimes you need something a little bit more thrilling, a little more exciting. Sometimes, you need a challenge.
Allow & Deny
We tend to come down on the side of Methods for one simple reason: Allow & Deny makes it very easy to get things wrong (or very hard to get things right, your pick).
But not everybody agrees with this, so we’re going to give you a chance to prove us wrong while demonstrating your Meteor mastery.
This MeteorPad contains the code for a simple chat app, where users can log in, post messages, and like each other’s messages.
Here’s the challenge: add a security layer for the
update operation using only Allow & Deny.
A few notes:
- Message insertion is already done through a method, so you can ignore it.
- You can also ignore the
- Users should only be able to edit their own messages.
- Users should be able to like anybody’s messages once.
- Liking should also update a
likesCountproperty that holds the total number of likes on the message document.
- Message editing is not built in the UI, but you can run commands using the browser console to emulate it.
- You can use any third-party package you like as long as you don’t use Meteor Methods.
If you’re ready, go ahead and fork this pad to get started!
Once you’re done, post a link to your solution here in the comments or in this Crater thread (or both).
I’ll post the solution (or at least, my interpretation of it) in an upcoming blog post later this week.
The main prize will be me analyzing your code and letting you know where you made a mistake (or if there are none, bowing before your Meteor magnificence).
Additionally, we’ll pick someone at random from the correct submissions and send them a Discover Meteor t-shirt. If there are no correct submissions, we’ll just keep the shirt! (Just kidding! If there are no correct answers we’ll pick someone at random from all participants.)
So let’s get started!