Loopback-datasource-juggler: User create default user is not working

Created on 27 Oct 2018  ยท  17Comments  ยท  Source: loopbackio/loopback-datasource-juggler

Code to create the default user:

User.create([
       {username: 'Testing', email: '[email protected]', password: '@pass2345'},
      ], function(err, user) {
console.log(user);
})

Package list

npm list|grep loopback
โ”œโ”€โ”€ [email protected]
โ”œโ”€โ”ฌ [email protected]
โ”‚ โ”œโ”€โ”ฌ [email protected]
โ”‚ โ”‚ โ””โ”€โ”ฌ [email protected]
โ”‚ โ”œโ”€โ”ฌ [email protected]
โ”‚ โ”œโ”€โ”ฌ [email protected]
โ”‚ โ”œโ”€โ”ฌ [email protected]
โ”‚ โ”‚ โ”œโ”€โ”€ [email protected]
โ”œโ”€โ”ฌ [email protected]
โ”œโ”€โ”ฌ [email protected]
โ”‚ โ”œโ”€โ”ฌ [email protected]
โ”œโ”€โ”€ [email protected]
โ”œโ”€โ”ฌ [email protected]
โ”œโ”€โ”ฌ [email protected]
โ”œโ”€โ”ฌ [email protected]
โ”‚ โ”œโ”€โ”ฌ [email protected]
โ”œโ”€โ”ฌ [email protected]
โ”‚ โ”œโ”€โ”ฌ [email protected]

Issue:

loopback:connector:postgresql {"command":"SELECT","rowCount":0,"oid":null,"rows":[],"fields":[{"name":"realm","tableID":18956,"columnID":1,"dataTypeID":25,"dataTypeSize":-1,"dataTypeModifier":-1,"format":"text"},{"name":"username","tableID":18956,"columnID":2,"dataTypeID":25,"dataTypeSize":-1,"dataTypeModifier":-1,"format":"text"},{"name":"password","tableID":18956,"columnID":3,"dataTypeID":25,"dataTypeSize":-1,"dataTypeModifier":-1,"format":"text"},{"name":"email","tableID":18956,"columnID":4,"dataTypeID":25,"dataTypeSize":-1,"dataTypeModifier":-1,"format":"text"},{"name":"emailverified","tableID":18956,"columnID":5,"dataTypeID":16,"dataTypeSize":1,"dataTypeModifier":-1,"format":"text"},{"name":"verificationtoken","tableID":18956,"columnID":6,"dataTypeID":25,"dataTypeSize":-1,"dataTypeModifier":-1,"format":"text"},{"name":"id","tableID":18956,"columnID":7,"dataTypeID":23,"dataTypeSize":4,"dataTypeModifier":-1,"format":"text"}],"_parsers":[null,null,null,null,null,null,null],"RowCtor":null,"rowAsArray":false} +2ms
  loopback:juggler:utils Sanitizing query object: **{"username":"Testing","password":"$2a$10$Nv5d4MmD4JOcz.RMaO8SQ.ilaRgGPA0KPoOAolzkCHGMhCkn2uPRO","email":"[email protected]"} +4ms
Potential security alert: hidden/protected properties ["password","verificationToken"] are used in query.
  loopback:connector:postgresql SQL: INSERT INTO "public"."user"("username","email") VALUES($1,$2) RETURNING "id"
  loopback:connector:postgresql Parameters: ["Testing","[email protected]"] +2ms**
  loopback:connector:postgresql error: null value in column "password" violates not-null constraint
  loopback:connector:postgresql     at Connection.parseE (/home/vagrant/metal/node_modules/pg/lib/connection.js:554:11)
  loopback:connector:postgresql     at Connection.parseMessage (/home/vagrant/metal/node_modules/pg/lib/connection.js:379:19)
  loopback:connector:postgresql     at Socket.<anonymous> (/home/vagrant/metal/node_modules/pg/lib/connection.js:119:22)
  loopback:connector:postgresql     at Socket.emit (events.js:182:13)
  loopback:connector:postgresql     at addChunk (_stream_readable.js:283:12)
  loopback:connector:postgresql     at readableAddChunk (_stream_readable.js:264:11)
  loopback:connector:postgresql     at Socket.Readable.push (_stream_readable.js:219:10)
  loopback:connector:postgresql     at TCP.onread (net.js:638:20) +2ms
  loopback:connector:sql Error: {"name":"error","length":216,"severity":"ERROR","code":"23502","detail":"Failing row contains (null, Echo, null, [email protected], null, null, 6).","schema":"public","table":"user","column":"password","file":"execMain.c","line":"1699","routine":"ExecConstraints"} "INSERT INTO \"public\".\"user\"(\"username\",\"email\") VALUES($1,$2) RETURNING \"id\"" ["Testing","[email protected]"] +0ms

Most helpful comment

Please try [email protected]

All 17 comments

There was a change in loopback-datasource-juggler today here is the link to the CHANGES.md
https://docs.strongloop.com/display/JA/Updates+to+loopback-datasource-juggler

Apparently they did some changes on how hidden/protected properties are handled and now they are not being sent in the query, also the message Potential security alert: hidden/protected properties [] are used in query. is displayed

I could not find any documentation about this change so as a temporary fix i suggest to downgrade to [email protected]

I have the same issue after upgrading from 3.24.0 to 3.25.0. How is there no changelog about this and why does loopback update to this version dependancy if it breaks user create functionality? Or am I missing something?

@raymondfeng is there any documentation on what needs to be changed to be able to update to 3.25.0?

Sorry for the break. I'll investigate.

The change was introduced by https://github.com/strongloop/loopback-datasource-juggler/pull/1638 to protect sensitive information from being guessed.

Please try [email protected]

Yes, works ok with mongo and 3.25.2! Thanks

3.25 broke my application as well, 3.25.2 fixed some of the tests but not all. The remaining failed tests seem to involve one of the following:

  • A count operation with a condition on a hidden property
  • A hidden property with an object type (definition looks like {"prop": {"a": {"type": "String", "required": true}, "b": {"type": "String", "required": true}}})

@BostjanPisler @raymondfeng it worked for me on [email protected] but will try it on 3.25.2

@tvdstaaij Can you try to set prohibitHiddenPropertiesInQuery: false to your model/datasource?

it worked on 3.25.2 as well.

@raymondfeng Setting prohibitHiddenPropertiesInQuery: false on my MongoDB datasource does not seem to have any effect. Setting it in the model options of the models with hidden properties does; it makes the remaining tests pass and gets rid of the "Potential security alert" messages. Although it fills my console with "false" messages instead, presumably because of this line.

Is this going to be reopened? As it stands 3.25 still breaks user code.

@tvdstaaij What's the exact version of loopback-datasource-juggler do you use? Can you try 3.26.1?

@raymondfeng Issue still exists for me with 3.26.1 in the cases I mentioned earlier (count operation and property with object type).

Does prohibitHiddenPropertiesInQuery: false at datasource settings level help you? Please show your datasource config.

I assume the false output to console is gone.

@raymondfeng Yeah it looks like prohibitHiddenPropertiesInQuery works on model level now, and the false messages are gone. So that works as a workaround and I will include it in my application. I just assumed that this needs a proper fix because otherwise this is semver-major change that breaks any application doing the same or similar operations as I am doing. I have no idea how many other people use hidden properties like this and it's up to your to decide how to handle this -- but personally I would be in favor of making prohibitHiddenPropertiesInQuery false by default in 3.x if a fix is not reasonably possible, for the sake of maintaining API compatibility.

Was this page helpful?
0 / 5 - 0 ratings