This is a supporter for getblackboard.com; mainly for static API services. Let's see if this evolves into something else or not.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 

141 lines
8.0 KiB

/**
* WebSocket Server Settings
* (sails.config.sockets)
*
* These settings provide transparent access to the options for Sails'
* encapsulated WebSocket server, as well as some additional Sails-specific
* configuration layered on top.
*
* For more information on sockets configuration, including advanced config options, see:
* http://sailsjs.org/#!/documentation/reference/sails.config/sails.config.sockets.html
*/
module.exports.sockets = {
/***************************************************************************
* *
* Node.js (and consequently Sails.js) apps scale horizontally. It's a *
* powerful, efficient approach, but it involves a tiny bit of planning. At *
* scale, you'll want to be able to copy your app onto multiple Sails.js *
* servers and throw them behind a load balancer. *
* *
* One of the big challenges of scaling an application is that these sorts *
* of clustered deployments cannot share memory, since they are on *
* physically different machines. On top of that, there is no guarantee *
* that a user will "stick" with the same server between requests (whether *
* HTTP or sockets), since the load balancer will route each request to the *
* Sails server with the most available resources. However that means that *
* all room/pubsub/socket processing and shared memory has to be offloaded *
* to a shared, remote messaging queue (usually Redis) *
* *
* Luckily, Socket.io (and consequently Sails.js) apps support Redis for *
* sockets by default. To enable a remote redis pubsub server, uncomment *
* the config below. *
* *
* Worth mentioning is that, if `adapter` config is `redis`, but host/port *
* is left unset, Sails will try to connect to redis running on localhost *
* via port 6379 *
* *
***************************************************************************/
// adapter: 'memory',
//
// -OR-
//
// adapter: 'redis',
// host: '127.0.0.1',
// port: 6379,
// db: 'sails',
// pass: '<redis auth password>',
/***************************************************************************
* *
* Whether to expose a 'get /__getcookie' route with CORS support that sets *
* a cookie (this is used by the sails.io.js socket client to get access to *
* a 3rd party cookie and to enable sessions). *
* *
* Warning: Currently in this scenario, CORS settings apply to interpreted *
* requests sent via a socket.io connection that used this cookie to *
* connect, even for non-browser clients! (e.g. iOS apps, toasters, node.js *
* unit tests) *
* *
***************************************************************************/
// grant3rdPartyCookie: true,
/***************************************************************************
* *
* `beforeConnect` *
* *
* This custom beforeConnect function will be run each time BEFORE a new *
* socket is allowed to connect, when the initial socket.io handshake is *
* performed with the server. *
* *
* By default, when a socket tries to connect, Sails allows it, every time. *
* (much in the same way any HTTP request is allowed to reach your routes. *
* If no valid cookie was sent, a temporary session will be created for the *
* connecting socket. *
* *
* If the cookie sent as part of the connection request doesn't match any *
* known user session, a new user session is created for it. *
* *
* In most cases, the user would already have a cookie since they loaded *
* the socket.io client and the initial HTML page you're building. *
* *
* However, in the case of cross-domain requests, it is possible to receive *
* a connection upgrade request WITHOUT A COOKIE (for certain transports) *
* In this case, there is no way to keep track of the requesting user *
* between requests, since there is no identifying information to link *
* him/her with a session. The sails.io.js client solves this by connecting *
* to a CORS/jsonp endpoint first to get a 3rd party cookie(fortunately this*
* works, even in Safari), then opening the connection. *
* *
* You can also pass along a ?cookie query parameter to the upgrade url, *
* which Sails will use in the absence of a proper cookie e.g. (when *
* connecting from the client): *
* io.sails.connect('http://localhost:1337?cookie=smokeybear') *
* *
* Finally note that the user's cookie is NOT (and will never be) accessible*
* from client-side javascript. Using HTTP-only cookies is crucial for your *
* app's security. *
* *
***************************************************************************/
// beforeConnect: function(handshake, cb) {
// // `true` allows the connection
// return cb(null, true);
//
// // (`false` would reject the connection)
// },
/***************************************************************************
* *
* `afterDisconnect` *
* *
* This custom afterDisconnect function will be run each time a socket *
* disconnects *
* *
***************************************************************************/
// afterDisconnect: function(session, socket, cb) {
// // By default: do nothing.
// return cb();
// },
/***************************************************************************
* *
* `transports` *
* *
* A array of allowed transport methods which the clients will try to use. *
* On server environments that don't support sticky sessions, the "polling" *
* transport should be disabled. *
* *
***************************************************************************/
// transports: ["polling", "websocket"]
};