strongloop

I have a node app that I connect to from a browser using WebSockets. If I run this app under a supervisor ( slc run --cluster cpu myapp.js ), will a websocket connection be always forwarded to the same worker once established? Or will the supervisor do some sort of load balancing when forwarding messages send to this connection? strong-supervisor does absolutely no load balancing or clustering on its own: it auto-starts and configures node cluster ( http://nodejs.org/api/cluster.html ) Node cluster distributes connections at the TCP level, it knows nothing about the protocols running over them

I have some strange behavior after moving from RedHat linux to SUSE on AWS. Everything was working fine, before. Here is my relations: Category: { "name": "Category", "plural": "categories", "base": "PersistedModel", "relations": { ... "professions": { "type": "hasMany", "model": "Profession", "foreignKey": "" } } } Profession: { "name": "Profession", "plural": "professions", "base": "PersistedModel", "relations": { ... "category": { "type": "belongsTo", "model": "Category", "foreignKey": "" } } } The problem is that when I update an existing profession with: { "categoryId" : "..." } It doesn

In my loopback application, once i create the access token (after login), it remains valid in my application unless application stops. when application restarted it is not allowing previous access token. How can i make previous access token validate even after restarting the application? Your access token is getting stored by default in loopback memory . Therefore, it persists only until the application is restarted. open server/model-config.json "AccessToken": { "dataSource": "db", "public": false } This is the initial configuration of the Access Tokens . See here the storage datasource is db

Is it possible to hide the id attribute in a method in swagger-ui generated by explorer in Strongloop Loopback? I don want the user to create a new resource and send the id attribute. I know that if the user send the id it can be ignored but I want to hide it in the explorer. In order to hide the 'id' attribute, you need declare this field as hidden. In YOUR_MODEL.json file: { "name": "YOUR_MODEL", . . . "properties": { // your custom properties }, "hidden": ["id"], // this attribute specifies which attributes need to be hidden . . . } Be aware when a property declared as hidden: It's not

We are developing a REST service but we already have an infrastructure in place to manage users. But we want to leverage the authentication and authorization mechanism of Loopback. The requirement is to Add a remote method and receive the user credentials Manually verify the credentials through stored procedure call Generate the access token through Loopback Going forward use Loopback authorization mechanisms such as roles in the application Should I be implementing a custom login service provider using Loopback's third party login support ? I couldn't find a very good resource on this area.

I'm working on a project that uses Loopback as a framework, and includes users and authentication. I added a password reset route generated and sent in an email, and everything seemed to be working correctly. Recently, I discovered that the password reset does not appear to be working. The process for resetting the password here is: Call password reset method for user Send email from reset event, including user ID and access token From reset link, set $http.defaults.headers.common.authorization to the passed token Call user.prototype$updateAttributes (generated by lb-ng) to update password

I'm reading Access control concepts of Loopback ( https://docs.strongloop.com/display/public/LB/Authentication%2C+authorization%2C+and+permissions ) and I don't understand how happened that Principal is not a model, but Role , RoleMapping , ACL are models with a full set of REST API methods and are listed in model-config.json ? When I tried to include Principal in model-config.json along with Role , RoleMapping and ACL I got error: "ACL": { "dataSource": "db", "public": false }, "RoleMapping": { "dataSource": "db", "public": false }, "Role": { "dataSource": "db", "public": false }, "Principal"