In only 10 lines of code we've specified that inserts, updates and removes can only be completed if a user is logged in.

The callbacks passed to the Parties.allow are executed on the server only. The client optimistically assumes that any action (such as removal of a party) will succeed, and reverts the action as soon as the server denies permission.
If you want to learn more about those parameters passed into Parties.allow or how this method works in general, please, read the official Meteor docs on allow.

Meteor.user()

Let's work on ensuring only the party creator (owner) can change the party data.

First we must define an owner for each party that gets created. We do this by taking our current user's ID and setting it as the owner ID of the created party.

As you can see, we've added a label "Please, login to change party" that is
conditioned to be shown if user is not defined with help of an ngIf attribute, and
will be hidden otherwise.

Routing Permissions

Let's imagine now that we allow to see and change party details only for logged-in users.
An ideal way to implement this would be to restrict redirecting to the party details page when
someone clicks on a party link. In this case, we don't need to check access manually in the party details component itself because the route request is denied early on.

This can be easily done again with help of CanActivate property. You can do this with the PartyDetailsComponent, just like we did previous steps earlier with the PartiesFormComponent.

Now log out and try to click on any party link. See, links don't work!

But what about more sophisticated access? Say, let's prevent access into the PartyDetails view for those
who don't own that particular party.

It could be done inside of a component using canActivate method.

Let's add a canActivate method and CanActivate interface, where we get the current route's partyId parameter
and check if the corresponding party's owner is the same as the currently logged-in user.

Now log in, then add a new party, log out and click on the party link.
Nothing happens meaning that access is restricted to party owners.

Please note it is possible for someone with malicious intent to override your routing restrictions on the client.
You should never restrict access to sensitive data, sensitive areas, using the client router only.

This is the reason we also made restrictions on the server using the allow/deny functionality, so even if someone gets in they cannot make updates.
While this prevents writes from happening from unintended sources, reads can still be an issue.
The next step will take care of privacy, not showing users parties they are not allowed to see.

Summary

Amazing, only a few lines of code and we have a much more secure application!

We've added two powerful features to our app:

the "accounts-ui" package that comes with features like user login, logout, registration
and complete UI supporting them;

restricted access to the party details page, with access available for logged-in users only.