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
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 [
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:
count operation with a condition on a hidden property{"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.
Most helpful comment
Please try [email protected]