Learn Sails.js - Part 7

von Manuel am 05.10.2025 um 12:00 Uhr

The locks and coffers are in your charge. A ship carrying valuable cargo in open waters without guards is not a warship; it’s a target. It’s time to post the watch and secure this vessel.


Part 7: Guarding the Gangway (Authentication & Policies)


The Captain’s Briefing (Background and Theory)

So far, our ship has an open-gangway policy. Anyone can wander aboard, read the Captain’s Log (/logbook), and even create new treasure using our API. This is untenable. We need to distinguish between an anonymous visitor and a verified member of the crew. This process involves two distinct concepts: Authentication and Authorization.

Authentication: “Show Me Your Papers”

Authentication is the process of verifying who someone is. On the web, this is the classic login form. The user provides credentials (like a name and password), and the server checks if they are valid.

How does the server remember the user after they log in? Through a Session. When a user logs in successfully, the server gives their browser a special, secret cookie that acts like a temporary crew pass. On every subsequent request, the browser sends this cookie back, and the server uses it to retrieve that user’s session data (e.g., their user ID), confirming they are still “logged in.”

A critical part of authentication is securely storing passwords. You must never, ever store plain-text passwords in your database. We will use a one-way cryptographic hashing algorithm (bcrypt) to turn passwords into a long, irreversible string of characters. When a user tries to log in, we hash the password they provided and compare it to the hash in our database. The passwords are never stored in a readable format.

Authorization with Policies: “Are You on the List?”

Authorization happens after authentication. Now that we know who the user is, we must decide what they are allowed to do. An Able Seaman can access the mess hall, but only the Quartermaster can access the cargo manifest.

In Sails, authorization is handled by Policies. A Policy is a small middleware function that you place in api/policies/. It’s a guard who stands at the gangway of a specific controller action. The guard checks the request (e.g., “Does this person have a valid session ID?”) and decides to either: 1. Let them pass by calling next(). 2. Deny them access by sending a response like res.forbidden().

You assign these guards to their posts in the config/policies.js file. sailsjs.com explains that this file acts as your application’s master Access Control List (ACL). You create a map that says, “To access this action, you must first pass through these policies.” This provides a powerful, centralized place to manage your entire application’s security rules. blog.sailscasts.com highlights the most common and powerful pattern: deny access to everything by default, then explicitly grant access to specific actions.


Key Concepts Checklist


Mission Log: Quest - “Secure the Quarterdeck”

We will now lock down the Captain’s Log (/logbook). It will only be accessible to a logged-in Captain. We will create signup, login, and logout functions to manage this access.


Mission Debrief (Review & Outcomes)

Excellent work, Quartermaster. The gangway is secure. The ship is no longer open to just any port visitor.

You have successfully implemented a professional-grade authentication and authorization system. You learned how to securely handle passwords, manage user sessions, and use policies as intelligent guards for your application’s sensitive areas. By adopting the “default deny” strategy in config/policies.js, you have established a robust security posture that will serve you well as your application grows in complexity. The ship and its cargo are now safe under your watch.


Rewards