Note: You are viewing the Sails.js v0.9.x documentation. If you're looking for information on v0.8.x, please visit here.
The default 404 handler.
The default 500 error handler.
The adapters configuration object lets you create different global “saved settings” that you can mix and match in your models.
This is an asynchronous boostrap function that runs before your Sails app gets lifted (i.e. starts up). This gives you an opportunity to set up your data model, run jobs, or perform some special logic.
By default, Sails controllers automatically bind routes for each of their functions. Additionally, each controller will automatically bind routes for a CRUD API controlling the model which matches its name, if one exists.
When enabled, all non-GET requests to the Sails server must be accompanied by a special token, identified as the '_csrf' parameter.
While you’re developing your app, this config file should include any settings specifically for your development computer (db passwords, etc.)
This is a folder that contains the Language files for different locales.
The logger file configures the log level for your app, as well as the transport.
Policies are like any other system for authentication control. You can allow or deny access in fine granularity with policies.
Sails uses a number of different strategies to route requests. This section lists them top-to-bottom, in order of precedence.
Sails session integration leans heavily on the great work already done by Express, but also unifies Socket.io with the Connect session store.
These configuration options provide transparent access to Sails’ encapsulated pubsub/socket server for complete customizability.
Server-sent views are a classic and effective way to get your app up and running. Views are normally served from controllers, but by default, Sails also exposes routes to allow you to preview your viewsn in a browser.