How to prevent overloading JWT token - node.js

i'm using jwt token with node.js npm jsonwebtoken in order to manage my users authentication. above that i'm adding to the payload the user permissions which contains the user read and write to which section.
like so:
const payload = {
user: {
id: user.id,
permissions: user.account_permissions
}
};
jwt.sign(
payload,
config.get('jwtSecret'),
{ expiresIn: TIME},
(err, token) => {
if (err) throw err;
res.json({ token });
}
);
The account_permissions object looks somthing like that:
const permissions = {
platform: 'Management',
sections: [
{
sectionName: 'setup',
read: true,
write: true
},
{
sectionName: 'chat',
read: true,
write: true
},
{
sectionName: 'maintenence',
read: true,
write: true
},
{
sectionName: 'classes',
read: true,
write: true
},
{
sectionName: 'income',
read: true,
write: true
},
{
sectionName: 'announcements',
read: true,
write: true
},
{
sectionName: 'messages',
read: true,
write: true
}
],
school: shoolID
};
My question is ; every user can have many permissions objects to different platforms which in that case makes the jwt token to be very large (sometimes to big to be even sent in the header).
I have a middleware that checks the user permissions in every route, im trying to avoid saving that data in a database in order to save database calls. how can i avoid such an overloading.

Related

Does using sequelize ORM prevent sql injection

I'm new to backend so I would like to make sure the data saved to the database is safe. I already got an answer, but I would still like a second opinion.
What the app does...
A user inputs some text into an input field and the app checks if there are any "typos" / misuse of the word and informs the user how to correct the errors.
The text user inputs is saved to the database along with uuid for tracking changes made to the text during that session.
The app currently has no other interaction with database.
I might have gone overboard, trying to use Sequelize.Op.eq, but it returned that an error shown below.
Current working example:
const UserText = sequelize.define('userText', {
id: {
type: Sequelize.INTEGER,
primaryKey: true,
autoIncrement: true
},
uuidv4: {
type: Sequelize.TEXT,
},
userText_field: {
type: Sequelize.TEXT,
allowNull: false
}
});
async function addStringToTable(uuid, string ) {
try{
await UserText.create({
uuidv4: uuid ,
userText_field: string
});
} catch (e) {
console.log(e);
}
}
This code throws an error (is Sequelize.Op.eq needed?)
async function addStringToTable(uuid, string ) {
// Save the input string to the database
try{
await UserText.create({
uuidv4: { [Sequelize.Op.eq]: uuid },
userText_field: { [Sequelize.Op.eq]: string }
});
} catch (e) {
console.log(e);
}
}
//error:
ValidationErrorItem {
message: 'uuidv4 cannot be an array or an object',
type: 'string violation',
path: 'uuidv4',
value: [Object],
origin: 'CORE',
instance: [userText],
validatorKey: 'not_a_string',
validatorName: null,
validatorArgs: []
},
ValidationErrorItem {
message: 'userText_field cannot be an array or an object',
type: 'string violation',
path: 'userText_field',
value: [Object],
origin: 'CORE',
instance: [userText],
validatorKey: 'not_a_string',
validatorName: null,
validatorArgs: []
}
Follow up question is, since I have no other interaction with the database, is using ORM enough or should some other security measures be taken? Since there is no "admin" panel, no users, and in general no access to the database from the front end, is the database safe from tempering / unauthorised lookup? Is there anything else I should look into / take care of.
I know the followup question are too broad, but any advice would be welcome.

NodeJS OIDC Provider getting aud and resource server errors upgrade from 6.x to 7.x

I am trying to upgrade [node-oidc-provider]https://github.com/panva/node-oidc-provider from version 6.x to version 7.x. I am using the authorization code flow for a React application.
I am getting an error regarding aud(audience) being a required field for JWT tokens:
Error: JWT Access Tokens must contain an audience, for Access Tokens without audience (only usable at the userinfo_endpoint) use an opaque format
Looking at the code and documentation, I tried to update the aud field by defining a function in formats.jwt.customizers.
I am not sure if this is the right solution as after doing that, I faced an issue regarding invalid resource server configuration:
Error: invalid Resource Server jwt configuration
Below is my existing configuration (provided file is support/configuration.js):
module.exports = {
clients: [
{
"application_type": "web",
"grant_types": [
"authorization_code"
],
"id_token_signed_response_alg": "RS256",
"post_logout_redirect_uris": [
"http://localhost:3001"
],
"require_auth_time": false,
"response_types": [
"code"
],
"subject_type": "public",
"token_endpoint_auth_method": "none",
"introspection_endpoint_auth_method": "none",
"revocation_endpoint_auth_method": "none",
"request_uris": [],
"client_id_issued_at": 1622600472.0,
"client_id": "my_client_id",
"client_name": "Sample client application",
"client_secret_expires_at": 0.0,
"client_secret": "my_client_secret" ,
"redirect_uris": [
"http://localhost:3001/callback"
],
"client_background_uri": "/public/img/default.png",
"app_id": "sample_app"
}
],
clientBasedCORS: (ctx, origin, client)=>{
return true
},
interactions: {
url(ctx, interaction) { // eslint-disable-line no-unused-vars
return `/interaction/${interaction.uid}`;
},
},
cookies: {
keys: ['some secret key', 'and also the old rotated away some time ago', 'and one more'],
},
formats:{
AccessToken :'jwt',
customizers: { jwt: async(ctx, token, jwt)=>{
jwt.payload.aud = jwt.payload.iss
}}
},
claims: {
address: ['address'],
email: ['email', 'email_verified'],
phone: ['phone_number', 'phone_number_verified'],
profile: ['birthdate', 'family_name', 'gender', 'given_name', 'locale', 'middle_name', 'name',
'nickname', 'picture', 'preferred_username', 'profile', 'updated_at', 'website', 'zoneinfo'],
},
features: {
devInteractions: { enabled: false }, // defaults to true
resourceIndicators: {
enabled: true,
async useGrantedResource(ctx) {
return ctx.oidc.body && ctx.oidc.body.usegranted;
},
getResourceServerInfo(ctx, resource) {
if (resource.includes('wl')) {
return {
audience: resource,
scope: 'api:read api:write',
};
}
throw new errors.InvalidTarget();
},
defaultResource(ctx) {
if (ctx.oidc.body && ctx.oidc.body.nodefault) {
return undefined;
}
return 'urn:wl:default';
},
},
deviceFlow: { enabled: true }, // defaults to false
revocation: { enabled: true }, // defaults to false
},
jwks: {
keys: [/* keys left out for privacy*/]
},
};
This is working with me using resourceIndicators configuration that looks like:
resourceIndicators: {
enabled: true,
getResourceServerInfo: async (ctx, resourceIndicator, client) => {
return {
scope: 'api:read api:write',
audience: resourceIndicator,
accessTokenTTL: 2 * 60 * 60, // 2 hours
accessTokenFormat: 'jwt',
jwt: {
sign: { alg: 'RS256' },
},
}
}

How do I update a key in an array of objects in MongoDB?

I working on NodeJS backend API and trying to change a key in an array of objects from false to true in my MongoDB database. I am passing two conditions from the client: the email of the user and the email of the person that sent the user a message. I would like to change the boolean value of read to true.
Sample data:
{
_id: new ObjectId("6282163781acbcd969de3fc9"),
firstName: 'Amanda',
lastName: 'Nwadukwe',
role: 'Volunteer',
email: 'amandanwadukwe#gmail.com',
password: '$2a$10$YD5MQlMt0gqSULQOBNcEfOLr3vIK8eF4dqdLw3XctsIVgbnf54P32',
confirmPassword: '$2a$10$mnL0S1bDDkGVnKgqQP81mOew9aFdNTUCGOEs7LvWYRxzivN4hrtFS',
date: 2022-05-16T09:14:57.000Z,
messages: [
{
message: 'This is another message from Amanda',
sendersEmail: 'laju#gmail.com',
date: '2022-05-14T12:00:45.000Z',
read: false
},
{
sender: 'Amanda Nwadukwe',
message: 'This is another message from Amanda',
sendersEmail: 'amanda#gmail.com',
date: '2022-05-14T12:00:45.000Z',
read: false
}]
Desired Output:
{
_id: new ObjectId("6282163781acbcd969de3fc9"),
firstName: 'Amanda',
lastName: 'Nwadukwe',
role: 'Volunteer',
email: 'amandanwadukwe#gmail.com',
password: '$2a$10$YD5MQlMt0gqSULQOBNcEfOLr3vIK8eF4dqdLw3XctsIVgbnf54P32',
confirmPassword: '$2a$10$mnL0S1bDDkGVnKgqQP81mOew9aFdNTUCGOEs7LvWYRxzivN4hrtFS',
date: 2022-05-16T09:14:57.000Z,
messages: [
{
message: 'This is another message from Amanda',
sendersEmail: 'laju#gmail.com',
date: '2022-05-14T12:00:45.000Z',
read: true
},
{
sender: 'Amanda Nwadukwe',
message: 'This is another message from Amanda',
sendersEmail: 'amanda#gmail.com',
date: '2022-05-14T12:00:45.000Z',
read: false
}]
I am tried a lot of things with filtering but I have not been successful. Here is my code to change all the read to true. It is also not working.
app.post("/view_message", (req, res) => {
const email = req.body.email;
Users.findOneAndUpdate({ "email": email }, {$set:{"messages.$.read": true}}, (err, result) => {
console.log(result)
})
});
You missed to add a check to match the array element to be updated.
Playground
db.collection.update({
"email": "amandanwadukwe#gmail.com",
"messages.sendersEmail": "laju#gmail.com", //This did the trick
},
{
"$set": {
"messages.$.read": true
}
},
{
"multi": false,
"upsert": false
})
Just in case anyone needs it, to update all the read values for all objects in the array I used this:
User.findAndUpdateOne({
"email": "amandanwadukwe#gmail.com",
"messages.sendersEmail": "laju#gmail.com",
},
{
"$set": {
"messages.$[].read": true //Added square brackets
}
},
{
"multi": false,
"upsert": false
})

How to get user information using node oidc provider

I got access token and I will pass access_token to userinfo endpoint it throwing an invalid token provided error How to fix this Issue. I tried to debug why this error is throwing we have validateAccessToken method(userinfo.js) in this method check the access_token is exist or not exist using this code await ctx.oidc.provider.AccessToken.find(accessTokenValue); when i print this result it's showing undefined
oidc_configuration.js
const oidc = new Provider('http://localhost:3000', {
clients: [
{
client_id: 'oidcCLIENT',
client_secret: '...',
grant_types: ['refresh_token', 'authorization_code'],
redirect_uris: ['http://sso-client.dev/providers/7/open_id', 'http://sso-client.dev/providers/8/open_id'],
}
],
interactions: {
url(ctx, interaction) { // eslint-disable-line no-unused-vars
return `/api/v1/open_id/interaction/${interaction.uid}`;
},
},
cookies: {
keys: ['some secret key', 'and also the old rotated away some time ago', 'and one more'],
},
claims: {
address: ['address'],
email: ['email', 'email_verified'],
phone: ['phone_number', 'phone_number_verified'],
profile: ['birthdate', 'family_name', 'gender', 'given_name', 'locale', 'middle_name', 'name',
'nickname', 'picture', 'preferred_username', 'profile', 'updated_at', 'website', 'zoneinfo'],
},
features: {
devInteractions: { enabled: false }, // defaults to true
deviceFlow: { enabled: true }, // defaults to false
revocation: { enabled: true }, // defaults to false
},
jwks: {
keys: [
{
d: 'VEZOsY07JTFzGTqv6cC2Y32vsfChind2I_TTuvV225_-0zrSej3XLRg8iE_u0-3GSgiGi4WImmTwmEgLo4Qp3uEcxCYbt4NMJC7fwT2i3dfRZjtZ4yJwFl0SIj8TgfQ8ptwZbFZUlcHGXZIr4nL8GXyQT0CK8wy4COfmymHrrUoyfZA154ql_OsoiupSUCRcKVvZj2JHL2KILsq_sh_l7g2dqAN8D7jYfJ58MkqlknBMa2-zi5I0-1JUOwztVNml_zGrp27UbEU60RqV3GHjoqwI6m01U7K0a8Q_SQAKYGqgepbAYOA-P4_TLl5KC4-WWBZu_rVfwgSENwWNEhw8oQ',
dp: 'E1Y-SN4bQqX7kP-bNgZ_gEv-pixJ5F_EGocHKfS56jtzRqQdTurrk4jIVpI-ZITA88lWAHxjD-OaoJUh9Jupd_lwD5Si80PyVxOMI2xaGQiF0lbKJfD38Sh8frRpgelZVaK_gm834B6SLfxKdNsP04DsJqGKktODF_fZeaGFPH0',
dq: 'F90JPxevQYOlAgEH0TUt1-3_hyxY6cfPRU2HQBaahyWrtCWpaOzenKZnvGFZdg-BuLVKjCchq3G_70OLE-XDP_ol0UTJmDTT-WyuJQdEMpt_WFF9yJGoeIu8yohfeLatU-67ukjghJ0s9CBzNE_LrGEV6Cup3FXywpSYZAV3iqc',
e: 'AQAB',
kty: 'RSA',
n: 'xwQ72P9z9OYshiQ-ntDYaPnnfwG6u9JAdLMZ5o0dmjlcyrvwQRdoFIKPnO65Q8mh6F_LDSxjxa2Yzo_wdjhbPZLjfUJXgCzm54cClXzT5twzo7lzoAfaJlkTsoZc2HFWqmcri0BuzmTFLZx2Q7wYBm0pXHmQKF0V-C1O6NWfd4mfBhbM-I1tHYSpAMgarSm22WDMDx-WWI7TEzy2QhaBVaENW9BKaKkJklocAZCxk18WhR0fckIGiWiSM5FcU1PY2jfGsTmX505Ub7P5Dz75Ygqrutd5tFrcqyPAtPTFDk8X1InxkkUwpP3nFU5o50DGhwQolGYKPGtQ-ZtmbOfcWQ',
p: '5wC6nY6Ev5FqcLPCqn9fC6R9KUuBej6NaAVOKW7GXiOJAq2WrileGKfMc9kIny20zW3uWkRLm-O-3Yzze1zFpxmqvsvCxZ5ERVZ6leiNXSu3tez71ZZwp0O9gys4knjrI-9w46l_vFuRtjL6XEeFfHEZFaNJpz-lcnb3w0okrbM',
q: '3I1qeEDslZFB8iNfpKAdWtz_Wzm6-jayT_V6aIvhvMj5mnU-Xpj75zLPQSGa9wunMlOoZW9w1wDO1FVuDhwzeOJaTm-Ds0MezeC4U6nVGyyDHb4CUA3ml2tzt4yLrqGYMT7XbADSvuWYADHw79OFjEi4T3s3tJymhaBvy1ulv8M',
qi: 'wSbXte9PcPtr788e713KHQ4waE26CzoXx-JNOgN0iqJMN6C4_XJEX-cSvCZDf4rh7xpXN6SGLVd5ibIyDJi7bbi5EQ5AXjazPbLBjRthcGXsIuZ3AtQyR0CEWNSdM7EyM5TRdyZQ9kftfz9nI03guW3iKKASETqX2vh0Z8XRjyU',
use: 'sig',
}, {
crv: 'P-256',
d: 'K9xfPv773dZR22TVUB80xouzdF7qCg5cWjPjkHyv7Ws',
kty: 'EC',
use: 'sig',
x: 'FWZ9rSkLt6Dx9E3pxLybhdM6xgR5obGsj5_pqmnz5J4',
y: '_n8G69C-A2Xl4xUW2lF0i8ZGZnk_KPYrhv4GbTGu5G4',
},
],
},
});
// Heroku has a proxy in front that terminates ssl, you should trust the proxy.
oidc.proxy = true;
const callback = oidc.callback();
How to fix this issue
You're running without a persistent adapter, meaning an in-memory one is used, are you possibly restarting your server after receiving the access token before calling the userinfo endpoint?
After completing the authentication, you will get access_token as well as id_token. I think you were using id_token in place of access_token which is why you are seeing that error
Instead use access_token then you can see the details

How to create item if not exists and return an error if exists

I'm writing alexa skill and would like to check if user exists in MongoDB. My code works but I don't know how to define situation if user is already in a database :(
Everytime when I execute code I get:
"Hello Anna you are new here"
My user Anna is saved in MongoDB
But I would like to distinguish when my user is already in a database and react for that.
Does anybody smart has a solution for my problem?
var myName = "Anan1";
var userID = this.event.session.user.userId;
console.log(userID);
self = this;
User.findOneAndUpdate(
{userId: userID},
{$set:{name:myName}},
{upsert: true, new: false, runValidators: true},
function(err, doc){
if(err){
console.log("eeoror");
}
console.log(doc);
if (doc==null){
self.emit(':ask',
"Hello "+ myName +"you are new here")
}else {
self.emit(':ask',
"Hello "+ myName +"you are not new here")
}
});
It sounds like what you really want is a unique key constraint and not an upsert.
The unique key can be set in [mongoose] with either the schema field options:
const s = new Schema({ name: { type: String, unique: true }});
or by the index method:
Schema.path('name').index({ unique: true });
If an attempt is made to create a document that already has an entry for that key then an error will be thrown:
NOTE: violating the constraint returns an E11000 error from MongoDB when saving, not a Mongoose validation error.
As noted in comment earlier, you have two basic approaches to work out whether something was "created" or not. These are either to:
Return the rawResult in the response and check the updatedExisting property which tells you if it's an "upsert" or not
Set new: false so that "no document" is actually returned in result when it's actually an "upsert"
As a listing to demonstrate:
const { Schema } = mongoose = require('mongoose');
const uri = 'mongodb://localhost/thereornot';
mongoose.set('debug', true);
mongoose.Promise = global.Promise;
const userSchema = new Schema({
username: { type: String, unique: true }, // Just to prove a point really
password: String
});
const User = mongoose.model('User', userSchema);
const log = data => console.log(JSON.stringify(data, undefined, 2));
(async function() {
try {
const conn = await mongoose.connect(uri);
await Promise.all(Object.entries(conn.models).map(([k,m]) => m.remove()));
// Shows updatedExisting as false - Therefore "created"
let bill1 = await User.findOneAndUpdate(
{ username: 'Bill' },
{ $setOnInsert: { password: 'password' } },
{ upsert: true, new: true, rawResult: true }
);
log(bill1);
// Shows updatedExisting as true - Therefore "existing"
let bill2 = await User.findOneAndUpdate(
{ username: 'Bill' },
{ $setOnInsert: { password: 'password' } },
{ upsert: true, new: true, rawResult: true }
);
log(bill2);
// Test with something like:
// if ( bill2.lastErrorObject.updatedExisting ) throw new Error("already there");
// Return will be null on "created"
let ted1 = await User.findOneAndUpdate(
{ username: 'Ted' },
{ $setOnInsert: { password: 'password' } },
{ upsert: true, new: false }
);
log(ted1);
// Return will be an object where "existing" and found
let ted2 = await User.findOneAndUpdate(
{ username: 'Ted' },
{ $setOnInsert: { password: 'password' } },
{ upsert: true, new: false }
);
log(ted2);
// Test with something like:
// if (ted2 !== null) throw new Error("already there");
// Demonstrating "why" we reserve the "Duplicate" error
let fred1 = await User.findOneAndUpdate(
{ username: 'Fred', password: 'password' },
{ $setOnInsert: { } },
{ upsert: true, new: false }
);
log(fred1); // null - so okay
let fred2 = await User.findOneAndUpdate(
{ username: 'Fred', password: 'badpassword' }, // <-- dup key for wrong password
{ $setOnInsert: { } },
{ upsert: true, new: false }
);
mongoose.disconnect();
} catch(e) {
console.error(e)
} finally {
process.exit()
}
})()
And the output:
Mongoose: users.remove({}, {})
Mongoose: users.findAndModify({ username: 'Bill' }, [], { '$setOnInsert': { password: 'password', __v: 0 } }, { upsert: true, new: true, rawResult: true, remove: false, fields: {} })
{
"lastErrorObject": {
"n": 1,
"updatedExisting": false,
"upserted": "5adfc8696878cfc4992e7634"
},
"value": {
"_id": "5adfc8696878cfc4992e7634",
"username": "Bill",
"__v": 0,
"password": "password"
},
"ok": 1,
"operationTime": "6548172736517111811",
"$clusterTime": {
"clusterTime": "6548172736517111811",
"signature": {
"hash": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=",
"keyId": 0
}
}
}
Mongoose: users.findAndModify({ username: 'Bill' }, [], { '$setOnInsert': { password: 'password', __v: 0 } }, { upsert: true, new: true, rawResult: true, remove: false, fields: {} })
{
"lastErrorObject": {
"n": 1,
"updatedExisting": true
},
"value": {
"_id": "5adfc8696878cfc4992e7634",
"username": "Bill",
"__v": 0,
"password": "password"
},
"ok": 1,
"operationTime": "6548172736517111811",
"$clusterTime": {
"clusterTime": "6548172736517111811",
"signature": {
"hash": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=",
"keyId": 0
}
}
}
Mongoose: users.findAndModify({ username: 'Ted' }, [], { '$setOnInsert': { password: 'password', __v: 0 } }, { upsert: true, new: false, remove: false, fields: {} })
null
Mongoose: users.findAndModify({ username: 'Ted' }, [], { '$setOnInsert': { password: 'password', __v: 0 } }, { upsert: true, new: false, remove: false, fields: {} })
{
"_id": "5adfc8696878cfc4992e7639",
"username": "Ted",
"__v": 0,
"password": "password"
}
So the first case actually considers this code:
User.findOneAndUpdate(
{ username: 'Bill' },
{ $setOnInsert: { password: 'password' } },
{ upsert: true, new: true, rawResult: true }
)
Most options are standard here as "all" "upsert" actions will result in the field content being used to "match" ( i.e the username ) is "always" created in the new document, so you don't need to $set that field. In order to not actually "modify" other fields on subsequent requests you can use $setOnInsert, which only adds these properties during an "upsert" action where no match is found.
Here the standard new: true is used to return the "modified" document from the action, but the difference is in the rawResult as is shown in the returned response:
{
"lastErrorObject": {
"n": 1,
"updatedExisting": false,
"upserted": "5adfc8696878cfc4992e7634"
},
"value": {
"_id": "5adfc8696878cfc4992e7634",
"username": "Bill",
"__v": 0,
"password": "password"
},
"ok": 1,
"operationTime": "6548172736517111811",
"$clusterTime": {
"clusterTime": "6548172736517111811",
"signature": {
"hash": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=",
"keyId": 0
}
}
}
Instead of a "mongoose document" you get the actual "raw" response from the driver. The actual document content is under the "value" property, but it's the "lastErrorObject" we are interested in.
Here we see the property updatedExisting: false. This indicates that "no match" was actually found, thus a new document was "created". So you can use this to determine that creation actually happened.
When you issue the same query options again, the result will be different:
{
"lastErrorObject": {
"n": 1,
"updatedExisting": true // <--- Now I'm true
},
"value": {
"_id": "5adfc8696878cfc4992e7634",
"username": "Bill",
"__v": 0,
"password": "password"
},
"ok": 1,
"operationTime": "6548172736517111811",
"$clusterTime": {
"clusterTime": "6548172736517111811",
"signature": {
"hash": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=",
"keyId": 0
}
}
}
The updatedExisting value is now true, and this is because there already was a document that matched the username: 'Bill' in the query statement. This tells you the document was already there, so you can then branch your logic to return an "Error" or whatever response you want.
In the other case, it may be desirable to "not" return the "raw" response and use a returned "mongoose document" instead. In this case we vary the value to be new: false without the rawResult option.
User.findOneAndUpdate(
{ username: 'Ted' },
{ $setOnInsert: { password: 'password' } },
{ upsert: true, new: false }
)
Most of the same things apply except that now the action is the original state of the document is returned as opposed to the "modified" state of the document "after" the action. Therefore when there is no document that actually matches the "query" statement, the returned result is null:
Mongoose: users.findAndModify({ username: 'Ted' }, [], { '$setOnInsert': { password: 'password', __v: 0 } }, { upsert: true, new: false, remove: false, fields: {} })
null // <-- Got null in response :(
This tells you the document was "created", and it's arguable that you already know what the content of the document should be since you sent that data with the statement ( ideally in the $setOnInsert ). Point being, you already know what to return "should" you require to actually return the document content.
By contrast, a "found" document returns the "original state" showing the document "before" it was modified:
{
"_id": "5adfc8696878cfc4992e7639",
"username": "Ted",
"__v": 0,
"password": "password"
}
Therefore any response which is "not null" is therefore an indication that the document was already present, and again you can branch your logic depending on what was actually received in response.
So those are the two basic approaches to what you are asking, and they most certainly "do work"! And just as is demonstrated and reproducible with the same statements here.
Addendum - Reserve Duplicate Key for bad passwords
There is one more valid approach that is hinted at in the full listing as well, which is essentially to simply .insert() ( or .create() from mongoose models ) new data and have a "duplicate key" error throw where the "unique" property by index is actually encountered. It's a valid approach but there is one particular use case in "user validation" which is a handy piece of logic handling, and that is "validating passwords".
So it's a pretty common pattern to retrieve user information by the username and password combination. In the case of an "upsert" this combination justifies as "unique" and therefore an "insert" is attempted if no match is found. This is exactly what makes matching the password a useful implementation here.
Consider the following:
// Demonstrating "why" we reserve the "Duplicate" error
let fred1 = await User.findOneAndUpdate(
{ username: 'Fred', password: 'password' },
{ $setOnInsert: { } },
{ upsert: true, new: false }
);
log(fred1); // null - so okay
let fred2 = await User.findOneAndUpdate(
{ username: 'Fred', password: 'badpassword' }, // <-- dup key for wrong password
{ $setOnInsert: { } },
{ upsert: true, new: false }
);
On the first attempt we don't actually have a username for "Fred", so the "upsert" would occur and all the other things as already described above happen to identify whether it was a creation or a found document.
The statement that follows uses the same username value but provides a different password to what is recorded. Here MongoDB attempts to "create" the new document since it did not match on the combination, but because the username is expected to be "unique" you receive a "Duplicate key error":
{ MongoError: E11000 duplicate key error collection: thereornot.users index: username_1 dup key: { : "Fred" }
So what you should realize is you now get three conditions to evaluate for "free". Being:
The "upsert" was recorded by either the updatedExisting: false or null result depending on the method.
You know the document ( by combination ) "exists" via either the updatedExisting: true or where the document returns was "not null".
If the password provided was not a match for what already existed for the username, then you would get the "duplicate key error" which you can trap and respond accordingly, advising the user in response that the "password is incorrect".
All of that from one request.
That's the main reasoning for using "upserts" as opposed to simply throwing inserts at a collection, as you can get different branching of the logic without making additional requests to the database to determine "which" of those conditions should be the actual response.

Resources