Sequelize: Deprecation warning for String based operators

[krishangupta]

Since I upgraded to 4.13.2 I get a deprecation warning

sequelize deprecated String based operators are now deprecated. Please use Symbol based operators for better security, read more at http://docs.sequelizejs.com/manual/tutorial/querying.html#operators node_modules/sequelize/lib/sequelize.js:236:13

I do not use any string based operators, however, or any operators of any kind. I didn't even know what an operator was actually, which is why I was confused.

I can fix this by adding operatorsAliases: false when instantiating the Sequellize object as below. Should this not be the default though? Or can we have the warning and documentation more clearly state that operatorsAliases: false must be set in order to avoid the warning?

const sequelize = new Sequelize(
  config.RDS_DB_NAME,
  config.RDS_USERNAME, 
  config.RDS_PASSWORD,
  {
    host: config.RDS_HOSTNAME,
    dialect: 'mysql',
    logging: false,
    freezeTableName: true,
    operatorsAliases: false
  }
)

[rojerv]

The same error

[sushantdhiman]

This is a deprecation warning, reason behind which is clearly stated in http://docs.sequelizejs.com/manual/tutorial/querying.html#operators-security , I am sure you must have read it.

Let me distill this regardless, Most web frameworks in Node.js allow parsing a object like string to actual JS object. This becomes a major issue when developers are passing user input without sanitizing them to Sequelize methods.

For example, consider this sample of code

db.Token.findOne({
      where: {
        token: req.query.token
      }
);

Now a bad actor could pass token='{"$gt": 1}' which will make above query to become something like this

db.Token.findOne({
      where: {
        token: {
           $gt: 1
        }
      }
);

This is because $gt is a string based operator which can be injected as string. To mitigate this we introduced secure operators https://github.com/sequelize/sequelize/pull/8240

Secure operators are Symbols which can't be duplicated by such object conversion. If we were using above code with secure operators we get this state

db.Token.findOne({
      where: {
        token: {
           $gt: 1 // invalid, as Op.gt is an operator but $gt is not. This will throw an error
        }
      }
);

We cant make these symbol operators default for everyone as this would be a breaking change.

So what should you as a developer do now

1) If you follow good development practices and sanitize your user inputs properly, Go ahead and ignore this warning. We encourage you to switch your code base to use Op based operators as in v5 String based operators $gte, $lte .... will be disabled by default

2) If you think your inputs are not properly sanitized, please change your codebase to use Op (Symbol based operators).

You still want to use a few or all string operators, but dont want this warning

You can pass an operators map to operatorsAliases as explained in http://docs.sequelizejs.com/manual/tutorial/querying.html#operators-aliases

So in theory you can pass all current operators and disable this warning but be aware of this issue and dont forget to sanitize your user inputs.

More discussion and implementation details here

• https://github.com/sequelize/sequelize/issues/7310
• https://github.com/sequelize/sequelize/pull/8240

[krishangupta]

@sushantdhiman Thanks for the quick response. I would normally expect deprecation warnings when I had actually used the thing that was being deprecated. I was really hunting my code for any operators before I figured out what was going on.

You have this section of the docs.

You can limit alias your application will need by setting operatorsAliases option, remember to sanitize user input especially when you are directly passing them to Sequelize methods.

To me it wasn't clear where to set operatorsAliases, or what to set it to.

A couple suggestions if it's not just me who's confused.

1. In the security section mentioned above, tell people When instantiating Sequelize, you are required to specify Operator Aliases or specifically set this value to false (set operatorAliases: false)..

2. Set operatorAliases: false by default on the Sequelize constructor so that others dont get the depreciation warning. Not sure of the implications here.

Thanks for all the hard work on this project!

[alanpurple]

I have no "$" things anywhere in my start code, but still has that deprecation warning

[krishangupta]

I also get it when doing a migration fyi.

[trinitroglycerin]

This also occurs in findById - there's no way of passing operators here.

[ekamgit]

This occurs using the basic 'Getting started' example from the main page. I do not even have a single query. I literally have the following code in index.js and get the warning.

const Sequelize = require('sequelize');

const sequelize = new Sequelize('database', 'username', 'password', {
  host: 'localhost',
  dialect: 'mysql',

  pool: {
    max: 5,
    min: 0,
    idle: 10000
  }
});

[alanpurple]

So this warning sure is a bug, as mentioned by many people

[fedtuck]

same thing for me

[siguago]

Just add this to options.

operatorsAliases: false

[reservce]

I tried to use

const Op = Sequelize.Op;
const operatorsAliases = {...}

following this http://docs.sequelizejs.com/manual/tutorial/querying.html#operators-aliases
However I got error:
Invalid value [object Object]
when this code below run:

let options = {where: {}, raw: true};
...
options.where.name = {$ilike: `%${filters.name}%`};
options.where.duration = filters.duration;
...
Banners.findAndCountAll(options);

Before update operatorsAliases, everything works fine.
How can I fix this?

[ghost]

const Op = Sequelize.Op;
const sequelize = new Sequelize('test', 'test', 'pass1234', {
  host: '127.0.0.1',
  dialect: 'mysql',
  operatorsAliases: Op, // use Sequelize.Op
  pool: {
    max: 5,
    min: 0,
    idle: 10000
  },
})

[alanpurple]

@andy1028 thanks, this solves mine

and to Sequelizers, why operatorAliases: Sequelize.Op is not default? though "without it" is deprecated

[ghost]

for compatibility history release

[charlierudolph]

I'm experience this as reported by @danpantry that using findById appears to trigger this warning. Should that be extracted to its own issue?

[createthis]

Here is what this looks like if you use sequelize-cli and config.js or config.json:

const Sequelize = require("sequelize");
module.exports = { 
  development: {
    dialect: "sqlite",
    storage: "./db.development.sqlite",
    seederStorage: "sequelize",
    operatorsAliases: Sequelize.Op,
    /* "logging": console.log, */
  },  
  test: {
    dialect: "sqlite",
    storage: "./db.test.sqlite",
    operatorsAliases: Sequelize.Op,
    logging: false
  },  
  production: {
    dialect: "sqlite",
    storage: "./db.production.sqlite",
    seederStorage: "sequelize",
    operatorsAliases: Sequelize.Op,
    /* "logging": console.log, */
  }
}

[grantcarthew]

Please add operatorsAliases: Sequelize.Op to the beginner tutorial.
http://docs.sequelizejs.com/manual/installation/getting-started.html

Your getting started document shouldn't cause a deprecation warning.

I'm just starting to learn sequelize. First 11 lines of code and I am searching issues???

[Laurensdc]

Could somebody please provide an example of a where query with a symbolic operator?
I only find examples of the $or syntax, and the documentation is too limited.

I've brute forced all possible syntax variations I can think of, and can't get it to work.
I'm getting "Invalid value: {}" or my operators are completely ignored.
Been trying to simply get an OR clause to work for over an hour now...

[jimrand1]

I'm learning this as well. Working my way through "Node.js Web Development". Page 179, added "operatorsAliases: Sequelize.Op" to the YAML configuration file. Page 175, added "const Op = Sequelize.Op;" to the models/notes-sequelize.js file. Then, in each find line changed

return SQNote.find({ where: {notekey: key }})

to

return SQNote.find({ where: {notekey: { [Op.eq]: key } }})

Coming from the Microsoft world with SQL command parameters, this appears to be a good way to avoid SQL injection attacks.

I'm just guessing that the above is the suggested solution.

[yonjah]

@andy1028 @alanpurple please don't use the @andy1028 mentioned code.
Sequelize.Op is very different to the normal aliases being used by sequlize. it will cause your setup to behave in an unexpected manner introduce security issues and it probably not what you want any way.
Since your not using aliases you can probably just set aliases to false -

const sequelize = new Sequelize('test', 'test', 'pass1234', {
  host: '127.0.0.1',
  dialect: 'mysql',
  operatorsAliases: false, // disable aliases
  pool: {
    max: 5,
    min: 0,
    idle: 10000
  },
})

If you do want to use aliases please follow the suggestion in the documentation -

const Op = Sequelize.Op;
const operatorsAliases = {
  $eq: Op.eq,
  $ne: Op.ne,
  $gte: Op.gte,
  $gt: Op.gt,
  ...
};

const connection = new Sequelize(db, user, pass, { operatorsAliases });

It might look long but this enables ALL previously existing aliases. You can remove the ones you don't use from the operatorsAliases. for example if you only want to use '$gt' -

const operatorsAliases = {
  $gt: Sequelize.Op.gt
};
const connection = new Sequelize(db, user, pass, { operatorsAliases });

@Laurensdc you can see more examples in http://docs.sequelizejs.com/manual/tutorial/querying.html#basics

const Op = Sequelize.Op;

Post.findAll({
  where: {
    [Op.or]: [{authorId: 1}, {authorId: 2}]
  }
});

@krishangupta @danpantry Even if you don't use aliases in your code Sequelize enables them by default. This warning is especially intended to users like you who were never aware this aliases are enabled and weren't using them. Now you are aware of them and can disable them.

The only reason they are not disabled by default is that it will be a breaking change so will only happen on v5 but since there are minor security issues by enabling aliases and not properly sanitizing them (and it is impossible to sanitize aliases you are not aware of) we opt in to adding the warning on current version. You can ignore this warning if you really want to and sequelize will work exactly the same but you probably shouldn't.

We tried to explain the reason for aliases and this warning as best as we could but documentation can always be improved and if you have any suggestions a pull request will be appreciated

[jimrand1]

Is my assumption correct that Sequelize.Op sanitizes user input to avoid SQL injection attacks?

Assuming in the example above with the authorID, the user passes in two alternatives. Instead of hard coded values of 1 or 2, the ids are stored in variables id1 and id2. Should the query then be:

Post.findAll({
where: {
[Op.or]: [{authorId: { [Op.eq]: id1 }}, {authorId: { [Op.eq]: id2 }}]
}
});

[yonjah]

@jimrand1 You are correct that this change was done to reduce the chance of injections.
The query you mentioned should work as well. but you don't have to use the Op.eq there since it will be the operator used in this case anyway.

So if you never used operators before ('$eq', '$or', '$gt' etc... ) you don't need to use the equivalent Op.### now and you can use Sequelize exactly as you used before.

But you should be aware that even if you were not using them they can still be injected so unless you disable them or explicitly select the ones you want to use you'll see this warning

[Laurensdc]

@yonjah Thank you so much!

I don't even know what I was doing wrong at this point, but I've got my queries working with proper symbolic operators.

I find the docs to be a tad too minimalistic on this part, since most examples are under 'Combinations', and are quite confusing in my opinion.

Old:

BComponent.findAll({
    where: {
        type: {
            $or: [req.body.type, 'B']
        }
    },
})

New option 1 that's working:

BComponent.findAll({
    where: {
        [Op.or]: [{type: req.body.type}, {type: 'B'}]
    },
})

New option 2 that's working:

BComponent.findAll({
    where: {
        type: {
            [Op.or]: [req.body.type, 'B']
        }
    },
})

Cheers!

[trinitroglycerin]

@yonjah my only suggestion is that it was incredibly confusing to see this happen in findById where I have no way of knowing I am using any operators without delving into the implementation detail of code. I don't think passing this buck onto the user is a good idea in this specific case, but I understand the reasoning for not enabling operator aliases for all methods.

It's just super surprising behaviour and does not instill confidence that I get a warning when using a library-supplied method in the only way I can use it and am told that I am doing something wrong.

[sylver]

Not really a major issue, but kind of annoying in the logs.
I'm unable to get rid of this deprecation warning about something I'm not even using, and I tried all the different suggestions above.

This warning should definitely not show up by default unless related to a misused of this option.

[yonjah]

@Laurensdc I'm happy you figured it out. pull requests that improve the docs are always welcomed.

@danpantry You'r not seeing this warning when your using findById or any other query method your seeing it when you define a Sequelize instance without setting the operatorsAliases property.
You don't have to dive into any implementation detail just follow the supplied Docs url and read the information provided there. If the docs are not enough to explain this issue they need to be fixed.

@sylv3r I'm sorry you still having trouble defining Sequelize properly so it wont show this warning.
You should first follow http://docs.sequelizejs.com/manual/tutorial/querying.html#operators-security and make sure you understand the issue and how to set operatorsAliases to match with you own setup.

[Laurensdc]

@yonjah First time I'm doing a PR on a big project. Did I do it right? #8608

[sylver]

@yonjah ok, my mistake, the configuration actually worked well while instanciating Sequelize.
However I'm having the same warning when using sequelize-cli to run the migrations. How to get rid of it on the cli too ?

I tried to add it in my config file without success :

const env = process.env.NODE_ENV

module.exports = {
  [env]: {
    operatorsAliases: false,
    url: process.env.DATABASE_URL,
    dialect: 'psql'
  }
}

and this (suggested above by @createthis) doesn't work either :

const Sequelize = require("sequelize")
const env = process.env.NODE_ENV

module.exports = {
  [env]: {
    operatorsAliases: Sequelize.Op,
    url: process.env.DATABASE_URL,
    dialect: 'psql'
  }
}

I still think this option should be false by default.

[baptistemanson]

We made the same mistake as the "magic quotes" situation in the PHP community 10 years ago. Between retro-compatibility and security, we have to choose our camp and cannot do both.

• we failed at retro-compatibility because everybody has to update their configuration.
• we failed at reinforced security doesn't work because there is a clear opt-out path
• we failed at keeping it easy because I don't know why would I want to customize the operator aliases, it doesn't give me any value. It is insane configuration over convention.

We should target any of those two options:

• So it is either a deprecation warning WHEN using the deprecated feature, in anticipation of a BC if the security problem is too important or
• an opt-in only feature for those who want to raise security.

[yonjah]

@sylv3r Please don't use the code from your second example. You can see my previous comment about it here https://github.com/sequelize/sequelize/issues/8417#issuecomment-341617577
I'm not sure why your get this error with sequelize cli. It might be faster to open an issue in it's repo with a bit more info https://github.com/sequelize/cli . But even with this warning the cli should work as before.

@baptistemanson I disagree with your analysis "magic quotes" failed not because of compatability vs security issue, but because it's security benefits were questionable and it probably caused more security concerns than it solved (there is no benefit in quoting every input with no context whatsoever just false sense of security).

Folowing your points I feel reassured in the way we chose to address this issue -

we failed at retro-compatibility because everybody has to update their configuration.

No one has to update his configuration as Sequelize will fall back to original defaults. You need to update your configuration if you don't want to see the warning but as many people mentioned here it is at worst a minor inconvenience. In the next major release of Sequlize we do plan to have the default changed to the more secure disabled aliases (setting operatorsAliases to false) so anyone who make the change now saves himself form having to do it in the future (though it's really hard to predict what other changes will come in the next major version)

we failed at reinforced security doesn't work because there is a clear opt-out path

There is no clear opt-out path. There is actually a clear opt-in path. As you can see from most comments here most users set the aliases to false optin in for a more secure setup. Enabling aliases is still easy but the way we chose to implement it requires the user to be aware of every alias being enabled. that also also solved any security concern we had with aliases which was mostly user awareness issue. So as long as you optin and understand this issue you end up with a more secure system than you had before even if you ended up optin to the defaults.

we failed at keeping it easy because I don't know why would I want to customize the operator aliases, it doesn't give me any value. It is insane configuration over convention.

It's easy if you don't want to configure them just set it to false. configuration is always better than conventions (Ember.js for example chose the no configuration path and is struggling to attract any user base compared to even smaller and much younger frameworks). The only place where configuration fails over conventions is when the defaults are not chosen correctly and this is what we're seeing here. Unfortunately this has been an implicit convention and effectively the default since v2 and we cannot change the defaults on this version without braking all our users apps and falling to the traps you mentioned before. As a minor compromised we added the warning explaining the issue until the default will be changed.

• So it is either a deprecation warning WHEN using the deprecated feature, in anticipation of a BC if the security problem is too important or
• an opt-in only feature for those who want to raise security.

I totally disagree with this point of view. Security should always be opt-out never opt -in. If security is opt-in 99% of your user will not be aware of the security issue turning it into unknown unknown so no chance they'll ever optin even if it has no affect on the way they use the library. But the other way around users will quickly notice if there setup is missing some feature they crucially need and that being blocked by some security feature and if they decide to disable it is is up to them to make sure they understand the issue and mitigate it.

Recently Mogodb had a security fiasco since many production installation had no auth enabled what so ever. It is not a chance that Mysql Postgres and MsSql has no external access by default it might make it a bit harder to setup initially but at least you don't end up loosing your entire data.

[chornbe]

I'm ignoring the startup warning at this point. I literally have ZERO queries in my starting application and am getting this warning just starting up Sequelize in the app's startup routine, but not actually asking for any data. Not even logging in yet. So, it is a bug, right?

Here's the basics of my startup... (some cruft cut out for brevity)

`passport.use(new LocalStrategy(passportStrategies.local));

passport.serializeUser(function (user, done) {
done(null, user.id);
});

passport.deserializeUser(function (id, done) {
console.log( "DeserializeUser: " + id );
done( err, null );
});

var app = express();

app.set("port", process.env.PORT || 8000);

// set up database then start server
models.sequelize.sync().then(function() {
http.createServer(app).listen(app.get("port"), function() {
log.info("Listening on port " + app.get("port"));
});
});
`

[trinitroglycerin]

@chornbe as was clarified above, the issue occurs upon construction of a sequelize instance when you don't modify the configuration

I completely agree with @baptistemanson fwiw.

I think, as should be evidenced by the number of people replying here that this was a failed approach or at the very least the way in which the warning is written is confusing. Users probably shouldn't have to refer to github issues to understand a warning IMO - take a look at how the Rust compiler does things, it's absolutely fantastic.

[Klejman]

Found that if I added the operatorsAliases (set to false) in my config.json file it resolved this issue...
{
"development": {
"username": "root",
"password": "",
"database": "todolist",
"host": "127.0.0.1",
"dialect": "mysql",
"operatorsAliases": false
}

[baptistemanson]

Dear @yonjah , thanks for taking the time of responding and exposing your point of view.

I do not choose the char encoding or the timezone of a database session with Sequelize. It has been chosen by convention and convenience.
When I choose a text field with Sequelize, do I have to get into the complexity of choosing between the native text, char varying, binary searchable or? If I build an index, would I have to build a GIN, GIST, Binary, Hash...? Do I have to configure the fact that I don't want any replication?

My point is I usually tend to avoid bold statements like "configuration is always better over convention" or its counterpart, as it frame me into making dogmatic mistakes instead of making educated choices ;).

When you introduced the operators, you zoomed in and developed a very valuable expertise around it that I will never have. You unburied issues. Thanks for doing so, it is great someone put the focus and time and talent on this problem. Now the way we share your knowledge and expertise with the community is what is discussed here, not the motivations behind. It is all and all positive feedback and we are eternal learners after all. We expose this complexity from the get go to:

• who start with Sequelize and didn't reach the doc talking of the operators yet
• who never heard of a SQL injection and would want protection built-in,
• who don't know what is a symbol in JS
• who never used string parsing in queries with Sequelize
• who always sanitize their parameters in 'cause their framework does so
• who will never customize the operators in any way
• who upgrade Sequelize

.. the solution we built for them is in my opinion not the right one. My guess is that population of developers is the majority.
I think we could have picked some default that avoid SQL injection for those people and could have triggered the warning only when we see a request using it.

[yonjah]

@baptistemanson I don't think it's such a bold statement. Both timezone and charset are available as options for you to set in Sequelize the reason you never use them is because they were set with a proper default that most users don't need to change. It shows the value of configuration over convention since if we didn't have the configuration option and just expected everyone to use utf-8 and utc with no option to change it even if it will be ok with most users, we will still have a lot of users who will have trouble using Sequelize.
As I said before the only place where convention might be better than configuration is where defaults are not properly selected which is what we have with operatorsAliases due to legacy issues.
Maybe there are other places where convention is better than configuration but I never stumbled into them.

I think we could have picked some default that avoid SQL injection for those people

We couldn't change the default with v4 since it and v2-3 all shipped with those operators enabled.
We could have waited to v5 knowing that we might have some users that are affected from this minor security issue. Out of lack of time I didn't port this fix to v3 but it means that we probably have a lot of v3 users who do not see this warning even they are affected I don't think we have many users who still use v2.

I don't know when v5 will be out but you think Sequelize users will be better of not knowing about this issue for another year or so ?

and could have triggered the warning only when we see a request using it.

Again not something we could do. If someone is injecting an operator into your code it is probably to late for you. Even if you are actively monitoring your logs and immediately see the warning as the injection goes it already went through

We expose this complexity...

Again I disagree with this point.
Lets divide the users you listed into two groups

• Novice users who are mostly clueless about security and don't care that much
• Experts who are aware of security issue and care to know what they do

With the first group there is not much you can do and they will probably ignore the warning any way if they decide to follow it and check it hopefully they'll figure out (as any one else who came to this thread) that all they need to do is set operatorsAliases to false (which should have been the default but as I explained it cannot for v4)

They set it once and they forget about it. No need to know about operators symbols injections or anything else unless they want to (and they probably should)

The second group are experts and probably will read the info and understand it. They might not know anything about symbols and they don't need to know anything about it but if they care about security they should probably check why the new operators were chosen instead of the old ones. They should also understand what kind of injections we are trying to minimize since it is not SQL injections and they are irrelevant to this issue.

Any way I totally agree that this would have been much better if we could have changed the default to disable aliases. There would be no need for the warning most users wouldn't even notice and those who will can easily enable the one they need or use the new operators.

[baptistemanson]

Thanks for your long answer. We don't have the same interpretation of "Convention over Configuration." In my interpretation, and quoting its inventor: "... a developer only needs to specify unconventional aspects of the application. " It means that everything can be configured, but is BY default at a smart value.
Whatever we call it, we are in agreement it is the right approach.

Let's do the same with operators, and switch them ON with no warning by default and update all tutorials accordingly. Then we trigger a FATAL if we see a query no using operators it, with a link pointing to information on how to migrate and or deactivate it if required (ala React).

[chornbe]

Bottom line: imo it’s a user- / dev-hostile move.

On Nov 17, 2017, at 1:27 PM, Baptiste Manson [e-mail] wrote:

Thanks for your long answer. We don't have the same interpretation of "Convention over Configuration." In my interpretation, and quoting its inventor: "... a developer only needs to specify unconventional aspects of the application. " It means that everything can be configured, but is BY default at a smart value.
Whatever we call it, we are in agreement it is the right approach.

Let's do the same with operators, and switch them ON with no warning by default and update all tutorials accordingly. Then we trigger a FATAL if we see a query no using operators it, with a link pointing to information on how to migrate and or deactivate it if required (ala React).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[yonjah]

@baptistemanson I totally agree the buzz words are less important. The important thing is to have properly selected default that most of our user wont ever change.

If you think tutorials still lacking important information you are welcome to submit a pull request (as others in who joined this thread already did).
Luckly there is no need to change any code (other than the default) to get the behavior you are describing. So on next major all we need is to change the default (as anyway planned)

[dhessler]

@Laurensdc @reservce
and anyone else getting Error: Invalid value {} or possibly Error: Invalid value [object Object]:

I resolved the issue by updating node from v6.x to v8.9.1.

Also, be careful not to inadvertently drop Symbol properties if you are cloning/extending objects containing Symbol properties (e.g., via some lodash/underscore functions which only copy over _string keyed properties_).

[cpapidas]

I have the same problem, I get the following error on application start up sequelize deprecated String based operators are now deprecated. Please use Symbol based operators for better security, read more at http://docs.sequelizejs.com/manual/tutorial/querying.html#operators node_modules/sequelize/lib/sequelize.js:236:13
notice that my application is not run any query and the database is completely empty, as you see the error comes from sequelize

[chornbe]

Yeah, I went in and hacked out the code in sequelize.js to get around this rather poorly expressed change. There are cleaner ways to handle this than simply uttering an error when the actual user code hasn't yet executed any offending statements. It's silly.

[cpapidas]

The truth is that this warning does not affect the product actually but it's annoying to see it.

[vschoener]

Same problem here, new to Sequelize and nodejs, using the Getting started bring me this error and another :
error: Unable to connect to the database: Error: pool is draining and cannot accept work

[colinwong]

I agree with @chornbe. I'm new to Serielize and just started working with it. I built a simple script to test the connection. No queries ran. Just sequelize.authenticate(). That's it. Instantly the deprecation message comes up and I wasted a bunch of time trying to figure out where I needed to replace string based operators with symbols. Such a bad and silly idea.

[chornbe]

cpapidas, in a standard config, you're absolutely right, it's not terribly harmful. My concern is, as we see in this and other threads, it's displaying an error before anyone writes any actual code, so people are wasting time and resources trying to find and fix/mute code that shows an error/warning, without that code existing, and without any of their code triggering it. That's my problem with it; show me MY offending code doing something bad before telling me about something bad that may or may not ever even be a thing.

In addition, if you've wrapped your application in anything that might treat a depro-warn as an error, and creating a crash condition erroneously.... well, that should be self explanatory.

It's just kind of a user hostile - or at least user passive-aggressive - thing. :)

[adeelshahid]

To disable the deprecated notice. Set operatorsAliases: false either in:

• config.json

or in

• database options when connecting to sequelize

[dakdreams]

import Sequelize from "sequelize";

const config = {
  database: "toto",
  username: "postgres",
  password: "postgres"
};

const Op = Sequelize.Op;
const sequelize = new Sequelize(
  config.database,
  config.username,
  config.password,
  {
    dialect: "postgres",
    operatorsAliases: Op,
  }
);

a solution!!!

[hamza-openinvest]

Unfortunately, the suggestion above to get rid of the deprecation warning causes another bug... not sure if I should file here or under a new issue, but basically I have a one-to-many relationship:

TableB.belongsTo(TableA, { onDelete: 'RESTRICT' });
TableA.hasMany(TableB);

elsewhere in the code:

tableAInstance.getTableBs(); // call the helper method to get all TableB records for a TableA instance

Now, if I use operatorsAliases: Sequelize.Op, OR operatorsAliases: {} OR operatorsAliases: false, I get the same error thrown by sequelize:

Invalid value { TableAId: [ 6 ] }     // where 6 is the Id of the TableA instance

If I don't specify the operatorsAliases option (or set to true), everything works fine, but I get the deprecation warning. The only way I found to avoid the deprecation warning AND this bug is to do:

operatorsAliases: Sequelize.Op.LegacyAliases,

but then I don't get the security benefit I guess, because the legacy aliases are still there. Anyway, would love it if this bug was resolved so I can remove this hacky workaround. Thanks!

[ryemcc]

NB: the proper key is operatorsAliases not operatorAliases as is written incorrectly several places in this thread.

[yonjah]

@hamza-openinvest can you please open a new issue explaining how to reproduce this issue when setting operatorsAliases to false. Unless your code using a specific a alias you shouldn't get any errors and this is probably a bug in Sequelize (Make sure you reproduce it with the latest version though cause a few similar bugs were previously fixed).

Your temporary solution for using operatorsAliases: Sequelize.Op.LegacyAliases will work and maybe even operatorsAliases: Sequelize.Op.Aliases.
But you are right to assume that with both solutions you will miss the enhanced security features of disabling aliases.
I would suggest to just not set operatorsAliases until it is resolved. So you will still have the warning logged and you'll know it something need to be fixed.

If you care to do some more testing you can manually set the aliases from Op.Aliases and Op.LegacyAliases aliases one by one until you find the missing one that solves this issue (we than will need to find the place in the code that uses this alias and change to use the new operator) this might have been fixed already but if not might be a good first PR

As a side note as mentioned in previous comment in the discussion here never use operatorsAliases: Sequelize.Op as @dakdreams and others suggested. I'm not sure what other solutions people suggesting it tried that didn't work but passing in Sequelize.Op will not solve anything. It can introduce unexpected behavior and other issues and will only hide the warning.

[hamza-openinvest]

@yonjah Took me quite a bit of time to repro, because the problem seemed to be with sequelize, but it turns out the problem I described happens because the dataloader-sequelize wrappers need to be updated to use the non-deprecated syntax. Considering dataloader-sequelize still uses $and, I don't think this qualifies as a bug there either, just something that eventually should be updated.

So basically, I can't remove the aliases (at least not all of them) because dataloader-sequelize still relies on them, and therefore fails without them (in a somewhat confusing way). So I should still use the aliases, and should still see the deprecation warnings, until dataloader-sequelize catches up.

@mickhansen FYI... repro files in attached zip, though technically this is NOT a bug with either sequelize nor dataloader-sequelize. Let me know if you'd like a PR to update dataloader-sequelize.

repro-get-error.zip

[yonjah]

@hamza-openinvest this is a bug in dataloader-sequelize since all extensions should stop using the string aliases and use the new operators.

As a work around until this is fixed you can set operatorsAliases: {$and: Sequelize.Op.and}
This will only enable the $and operator and will not show the warning.
You will need to make sure users can't inject the $and alias into queries (which you should have done before anyway but now you only have to worry about $and and not about all the other aliases that were previously available )

[asci]

Now a bad actor could pass token='{"$gt": 1}' which will make above query to become something like this

sorry, I didn't get it, how string became an object?

[yonjah]

@asci This depends on how you parse and get user input.
Many node.js web frameworks (like express) will parse query strings ans other user input into js object.
You need to check the documentation of the web framework your using to see if this is possible and which formats are supported

[jhpratt]

@sushantdhiman Any possibility of printing a line number (or stack trace) on a deprecation notice? Optional, of course, but it would be great for debugging. Otherwise it's a complete pain to track down where it is.

[sushantdhiman]

5.0.0-beta.2 launched which removes this deprecation warning, with that Sequelize now defaults to symbol operators.

[matt212]

Hi @krishangupta @Ghost141 ,
thanks for update but warning still visible

my sequelize version is ^4.37.6
my node version is v8.5.0
and below is sequelize code snippet

const sequelize = new Sequelize(config.database, config.username, config.password, {
    host: config.host,
    dialect: config.dialect,
    pool: {
        max: 5,
        min: 0,
        idle: 10000
    },
    logging: false,
    freezeTableName: true,
    operatorsAliases: false
});

warning message

[SystemDisc]

The warning is not a bug. See https://github.com/sequelize/sequelize/issues/8417#issuecomment-334056048

The warning is displayed if you don't set operatorsAliases, and it absolutely should be displayed if operatorsAliases is not set to some mapping or is set to false.

operatorsAliases will be set to false by default in the future, but cannot be set to false by default before v5 because it's a breaking change. If you are not using any string-based operators (i.e. you're not using operators like $or, but instead you are using operators like [Op.or]), you absolutely should set operatorsAliases to false to explicitly forbid string-based operators and avoid the SQL Injection vulnerability.

[bdrazen]

@sushantdhiman So passing in a map doesn't actually rectify the vulnerability (beyond preventing the ones you don't specify), but suppresses the warning?

[yonjah]

@DBjelovuk If you don't want user input to contain operators other than backward compatibility I don't think there is any reason to use the map with aliases (so just set it to false).

If you use the map to set any operators you need to make sure you properly sanitize user input to make sure the aliases you defined are not used where they are not allowed. And since you (the developer) decided which aliases to use we trust you also sanitize input using them properly.

The vulnerability issue before using symbols was that many developers weren't aware of all the operators (if any) and so weren't properly sanitizing user input.
BTW I don't know of any other DB layer that implemented a similar fix even though most (if not all of them) are suffering from similar issues.

[SystemDisc]

@DBjelovuk Passing in a map that contains just the built-in symbol-based operators is silly and will have unexpected results. Instead, set operatorsAliases to false. Passing a map that contains the old string-based operators (or any string-based operators) will suppress the message, but will keep your software vulnerable.

[yonjah]

@DBjelovuk Passing in a map that contains just the built-in symbol-based operators is silly (but it will remove the vulnerability)

@SystemDisc If you mean passing Sequelize.Op as others suggested very early in this thread. It is not only silly but it will not solve the vulnerability (it might actually make it worse).

Passing a map that contains the old string-based operators (or any string-based operators) will probably suppress the message, but will keep your software vulnerable.

It will suppress the message. If the map is of aliases the developer is actually using, it will probably mitigate this vulnerability.

See my comment above and you can also refer to the original issue that we were trying to solve by deprecating the default string based operators https://github.com/sequelize/sequelize/issues/7310

[SystemDisc]

No, you're wrong. Using string-based operators at all will leave you vulnerable.

[yonjah]

No, you're wrong. Using string-based operators at all will leave you vulnerable.

@SystemDisc since you don't give any reason for your claims it's hard to know if I failed to properly explain this issue or if I fail to understand what it is your meaning.

Any way do to the nature of this issue it is a bit hard to speculate about vulnerable software even before we introduced the fix. But if you need to use aliases you can do it without introducing any security vulnerability into your code (you just need to do it properly as you do with any other code you write).

This is mostly a developer awareness issue so I'll be happy to provide more info if something is still not clear from the above discussion and docs.

[bdrazen]

@sushantdhiman

db.Token.findOne({
      where: {
        token: req.query.token
      }
);

Now a bad actor could pass token='{"$gt": 1}' which will make above query to become something like this

db.Token.findOne({
      where: {
        token: {
           $gt: 1
        }
      }
);

Would this not only pose a risk if req.query.token is first parsed into an object?

@yonjah @SystemDisc If you guys want to weigh in.

[SystemDisc]

@DBjelovuk depending on the framework and middleware you use, the chances of token[$gt]=1 being parsed to token = {gt: 2} by default is high. That's the entire vulnerability.

@yonjah If you did this:

  // ...
  operatorsAliases: {
    // ...
    $gt: 'greaterThan',
    // ...
  }
  // ...

and you were previously vulnerable to the token[$gt]=1 example, you'd still be vulnerable, but the payload would need to be token[greaterThan]=1. Hence, setting operatorsAliases to use any sort of string-based operators will perpetuate the vulnerability, but suppress the deprecation warning.

@DBjelovuk To clarify why Symbol-based operators avoid this pitfall, this is worth a read: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/for

[yonjah]

@DBjelovuk you are correct that this is only a risk if req.query.token can be an object.
Unfortunately many frameworks including express which is the most popular node framework will parse queries and other user input by default. So most users who use this kind of code are vulnerable.

@SystemDisc Ok I see what your getting at and what you are saying is correct.
But let me try and explain why the situation is not exactly the same.

========================
This got a bit long so TL;DR;

• Totally clueless and careless devs will always have vulnerabilities in their code. Using Symbol based operators only, will protect them a bit but they still have a lot of work they need to do to not be vulnerable
• Average devs if decide to enable aliases for an operator, will also be aware of the implications and will know what they need to do to avoid unexpected operators injection
• Always validate user input to be exactly of the type and structure you expect it to be. It doesn't matter if you only use Symbol based operators. not validating user input will come to bite you sooner or later

========================

Assume we have a clueless developer who uses express and does not validate any of his input.
He has a really badly written express middleware which validates session tokens like so -

async (req, res, next) => { //this is really bad code with vulnerabilities do not use it !!!
    const { token } = req.cookies;
    const session = await sessionModel.findOne({where: {token, status: 'valid' }});
    if (session) {
        req.session = session;
        return next()
    }
    res.sendStatus(401);
}
// A bit sad but this a real example taken from real code

Who ever wrote this code has no idea about sequelize operators.
He does not understand that if the token will be an object {$ne: ""} a valid session will be returned from the db. He does not know that with the wayexpress parses cookies, the token can actually be set to this object by an attacker.

So this code is completely broken.

Now we can't fully protect people from copy pasting code without understanding it or doing silly stuff like passing Sequelize.Op as the alias object. But if a developer is so clueless we can assume he has much more serious security issues in his code and no matter what we do from the library perspective, he will still be vulnerable.

So lets assume our developer who wrote the above code is not as clueless as that. He still not aware to all the library features but when he write code he at least tries to understand it and not just copy past what he finds online (BTW when implementing this fix I found many operators I and other contributors were not aware of. I think it is safe to say there are a lot of developers who will be happy to do the right thing if we just point them in the right direction)

Now lets say our developer is using Sequelize 4 and he see's the warning and decide to fix it.
If he goes to the doc reads them and even if just partially understand them. He is probably going to end up with setting operatorsAliases to false.

I know it's not much to go by, but I specifically tried to organize the docs so the first code example you see is going to be the more secure option. the API was also designed around that if you want to enable all the aliases as they were before you need to write quite a lot of code so the easiest thing to do is actually go with the more secure option.

If the dev do enable some aliases lets say -

    { operatorsAliases: { '!': Op.ne } }

It is true that to inject the same operator the only thing changed is the injection object is now {'!': ""} but the major difference now is that the developer is not as clueless as he was before.

At minimum he knows there is such a thing as operators and he chose "!" to be an operator. I would also argue that if he enabled it he is also using it somewhere with user input (no real reason to enable them otherwise) so he knows the user can use those operators and he make sure they are only used where he allows them to be used.

Though Sequelize behaves the same it is doubtful that the developer will leave his middleware code the same without validating user input (which is where the vulnerability was from the start).

[Kumfert]

Is there any way to reference the offending line of code with the deprecation warning? Folks with large existing codes can't be expected to fix 50-60 offenses at once. Rather, they need some kind of incremental feedback to recompile, see they've fixed 2 out of 50 correctly, and continue to chip away at the problem.

[hansfpc]

It Works :)

import Sequelize from 'sequelize'
import config from './constants'

const host = process.env.SERVER || config.DATABASE.SERVER
const database = process.env.NAME || config.DATABASE.NAME
const username = process.env.USERNAME || config.DATABASE.USER
const password = process.env.PASSWORD || config.DATABASE.PASSWORD
const dialect = process.env.DIALECT || config.DATABASE.DIALECT

export default new Sequelize(database, username, password, {
  host,
  dialect,
  logging: false,
  operatorsAliases: Sequelize.Op, /* here magic occurs */
})

[sushantdhiman]

^ @yonjah See, that's why it's deprecated in v5 :p

[yonjah]

@sushantdhiman that what I was referring in my previous comment (and TL;DR; first point)

The only issue I have with totally deprecating sting based operators is that if I look at my own endpoints every user input is validated with a tightly defined schema. If it's not in the schema it's not going to be validated.
If I'll want to allow users to use operators like GT LT in some APIs I don't want to write the parser myself (especially when it is available in sequelize) and I don't want to see a warning for stuff I specifically chose to enable. I don't have any aliases enabled at the moment so I don't care that much.

I think a more reasonable solution would be to totally deprecate aliases on the connection level but allow to enable specific aliases in the options for the query methods. It will still be abused by clueless users but it reduces the attack surface considerably.

But I certainly see your point and I can see why totally deprecating aliases has some merits to it.

[ndaidong]

Same unexpected warning here. I found Sequelize.Op.Aliases, so the following works for me:

const Sequelize = require('sequelize');
const {Aliases: operatorsAliases} = Sequelize.Op;

const {
  dbType: dialect,
  dbHost: host,
  dbPort: port,
} = require('../configs');

const sequelize = new Sequelize({
  dialect,
  host,
  port,
  operatorsAliases,
});

The longer version from documentation also works:

const Op = Sequelize.Op;
const operatorsAliases = {
  $eq: Op.eq,
  $ne: Op.ne,
  ...

[yonjah]

@ndaidong why unexpected ?
Any reason enabling all the operators ? which ones are you actually using in your code?
If your not using any than this code -

const sequelize = new Sequelize({
  dialect,
  host,
  port,
  operatorsAliases: false
});

Is the simplest and safest way to go

[ndaidong]

@yonjah do you mean that operatorsAliases should be disabled by default? then we will use Sequelize.Op to get the needed operator instead of pure string based keys?

[yonjah]

@ndaidong yes that would be the best option.
But even if you don't want to go and change all your code, assuming you use just a few operators like $gt and $lt why not only enable those ?

[ndaidong]

@yonjah thanks for pointing out that, I just tried to use Sequelize.

[SystemDisc]

@hansfpc and @ndaidong Please do not do that. Please instead set operatorsAliases: false.

import Sequelize from 'sequelize'
import config from './constants'

const host = process.env.SERVER || config.DATABASE.SERVER
const database = process.env.NAME || config.DATABASE.NAME
const username = process.env.USERNAME || config.DATABASE.USER
const password = process.env.PASSWORD || config.DATABASE.PASSWORD
const dialect = process.env.DIALECT || config.DATABASE.DIALECT

export default new Sequelize(database, username, password, {
  host,
  dialect,
  logging: false,
  // disable string-based operators, and do not set any aliases
  // (i.e. use the built-in Symbol-based operators
  operatorsAliases: false,
})

Perhaps we should disable commenting and end with a comment that explains it, because people keep jumping in and announcing that you should do something that's wrong.

[rojcyk]

Hi @yonjah, I encountered the issue myself and since I understood about 50% of the things mentioned here, your post where you mentioned a clueless developer resonated with me (I'm mainly a designer, with FE skills and I need to write a BE for one of my projects) = I'm most likely the clueless developer. Do you have any recommended 101 resources where I could dive into the security and at least take care of the most common offenses?

[yonjah]

@rojcyk there is a really good node best practice repo -
https://github.com/i0natan/nodebestpractices
With a large section about security -
https://github.com/i0natan/nodebestpractices#6-security-best-practices

If your really not sure about something I would try to open source it as much as you can and try to get some feedback from more experienced developers.

It's probably outside the scope of sequelize and this specific issue so feel free to DM me on twitter if you get stuck on anything

[Der-Alex]

Maybe I did understand something wrong, but I still get the deprecation warning even if I set operatorAliases to false:

const sequelize = new Sequelize(config.db, config.user, config.pw, {
    host: config.host,
    dialect: config.dialect,
    pool: config.pool,
    operatorAliases: false,
    logging: process.env.NODE_ENV === 'development'
});

What am I doing wrong and how do I remove that warning?
I am using sequelize 4.41.2

[SystemDisc]

It's operatorsAliases not operatorAliases.

This is a very common mistake.

[yuuk]

It's operatorsAliases not operatorAliases.

This is a very common mistake.

you are right!

[originalix]

const Op = Sequelize.Op;
const sequelize = new Sequelize('test', 'test', 'pass1234', {
  host: '127.0.0.1',
  dialect: 'mysql',
  operatorsAliases: Op, // use Sequelize.Op
  pool: {
    max: 5,
    min: 0,
    idle: 10000
  },
})

you are right!

[SystemDisc]

@originalix
I would strongly urge you to set operatorsAliases to false. Setting it to Op will almost certainly have unexpected consequences as stated further up in the comments. Setting operatorsAliases to false will disable string-based operators entirely, and only allow you to use the built-in Symbol-based operators. This seems to be your intention.

Example here:
https://github.com/sequelize/sequelize/issues/8417#issuecomment-417694104

Explanation here:
https://github.com/sequelize/sequelize/issues/8417#issuecomment-341617577

[spkellydev]

How come I use the CLI to generate a config.json and when I use the same CLI to run a migration, this operatorsAliases error gets thrown? It looks like the issue was finally closed last week, is my CLI just out of date?

[catamphetamine]

This warning is a bug.
Our code has no "operators".
Yet, calling new Sequelize() outputs the warning.

Update: operatorsAliases: false resolved the issue.
The warning text should be changed to include the operatorsAliases: false fix instructions.

[SystemDisc]

Everything you need to know about this can be found in my last post here: https://github.com/sequelize/sequelize/issues/8417#issuecomment-447437098

which references this example: https://github.com/sequelize/sequelize/issues/8417#issuecomment-417694104

and this explanation: https://github.com/sequelize/sequelize/issues/8417#issuecomment-341617577

I really wish someone would lock this thread because it seems like every few days someone interjects with "no, this is really a bug ... edit: no wait it's not" and sometimes with instructions which should not be followed.

[chornbe]

You’re missing the point, from others’ perspectives. People are feeling like they’re getting error reports when NOT using aliases and THAT is problem.

Full stop.

On Feb 5, 2019, at 2:50 PM, Zorn [e-mail] wrote:

Everything you need to know about this can be found in my last post here: #8417 (comment)

which references this example: #8417 (comment)

and this explanation: #8417 (comment)

I really wish someone would lock this thread because it seems like every few days someone interjects with "no, this is really a bug ... edit: no wait it's not" and sometimes with instructions which should not be followed. Do not set operatorsAliases: Sequelize.Op. Do set operatorsAliases: false.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[SystemDisc]

@chornbe You and others that feel that way are missing the point. The whole point of this change was to prevent users of apps which use sequelize from injecting parameters into someone's where condition. This change is specifically for people "feeling like they’re getting error reports when NOT using aliases", because if you're not using aliases but you do not have them disabled, you are open to the vulnerability that is being addressed here. If you are using string-based operators at all (or have string-based operators enabled at all) you are open to the vulnerability being addressed here.

Here is the vulnerability being addressed: https://github.com/sequelize/sequelize/issues/7310

[chornbe]

I promise you I'm missing zero points. When you institute a change that
affects an installed base, you default to the existing condition, and you
turn off the offending code. Minimal impact. What you don't do is suddenly
make thousands of developers go nuts trying to find what they believe is a
bug or a config error that doesn't exist. In 3 decades of IT work, I've
never instituted a change that has people panicking and up in arms for zero
practical reason like I've seen over this poorly implemented, documented,
and explain change.

Chris Hornberger
chris.[email protected]

On Tue, Feb 5, 2019 at 2:57 PM Zorn [e-mail] wrote:

@chornbe https://github.com/chornbe You and others that feel that way
are missing the point. The whole point of this change was to prevent users
of apps which use sequelize from injecting parameters into someone's where
condition. This change is specifically for people "feeling like they’re
getting error reports when NOT using aliases", because if you're not using
aliases but you do not have them disabled, you are open to the
vulnerability that is being addressed here. If you are using string-based
operators at all (or have string-based operators enabled at all)
you are open to the vulnerability being addressed here.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sequelize/sequelize/issues/8417#issuecomment-460780997,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHJ5ee0sMkMdCtP12qL3oa4zDuu5He2zks5vKeIbgaJpZM4Pss3F
.

[catamphetamine]

@SystemDisc Even though I see you as a confident and professional developer I still can agree with @chornbe 's argumentation here: this warning message is indeed much more cryptic than it should have been.

I raised this issue and the author of the library said he has somehow "fixed" it in the latest code.
https://github.com/sequelize/sequelize/issues/10414

A similar issue was with node-sass where the developers just threw in a cryptic deprecation warning in a new major version:
https://github.com/sass/node-sass/issues/2362
What it resulted in were hundreds (or thousands?) of developers panicking and trying to decypher what does the software complain about and what does it want.

The main point here is the communication issue.
If sequelize just was a bit more cooperative and examined the config to find that operatorsAliases: false is not set there and after that it would say something more human-readable like:

TLDR: $-operators will be removed in the next major version. First replace all of them with Sequelize.Op in code, then set operatorsAliases: false in your config, and then this warning will disappear. Read the link about why was this change introduced: https://...

Then no one would complain.

@SystemDisc I agree that your comment should be the last one in this thread.
That's why I'll delete this comment tomorrow.
I advice @chornbe does the same so that people coming from google aren't confused.
I also advice @krishangupta to edit his original post to link to @SystemDisc 's solution as the first line of it.

[SystemDisc]

@chornbe As was mentioned previously, having operatorsAliases set to false is the new default (starting in v5), but since it's a breaking change, it cannot be made the default without bumping the major version. The deprecation message clearly does not contain enough information - this is evidenced by the existence of this thread. However, people keep jumping in and creating more confusion. This is why the thread should be locked with a helpful summary at the end. Let's stop muddying the waters by posting incorrect instructions and claims about this deprecation message being a bug. If you're seeing the deprecation message, you do not have string-based operators disabled, period. It's not a bug. It's expected. You really, really should disable string-based operators, especially if you don't use them.

@catamphetamine Don't delete your comment, I'll just keep posting the TL;DR at the end of the thread.

TL;DR of this thread:

• In v4
  
  
  
  • Do not set operatorsAliases: Sequelize.Op.
  
  
  • Do set operatorsAliases: false.
  
  
  • Do double check that you're using operatorsAliases (with an s after operator).
    
    
    
    
    
    • operatorAliases is not a valid option.
    
    
    
  
  
  • If you are not using string-based operators, do not ignore this warning
    
    
    
    
    
    • Instead, disable string-based operators entirely using operatorsAliases: false. If you do not, you may be vulnerable: https://github.com/sequelize/sequelize/issues/7310
    
    
    
  
  
• in v5 (and probably future versions)
  
  
  
  • Do not set operatorsAliases. Not setting operatorsAliases in v5 gives you the same result that setting operatorsAliases: false in v4 did. Only define operatorsAliases in v5 if you are 100% sure you know what you're doing
  
  

Example code

https://github.com/sequelize/sequelize/issues/8417#issuecomment-417694104

Explanation

https://github.com/sequelize/sequelize/issues/8417#issuecomment-341617577

Original vulnerability being addressed

https://github.com/sequelize/sequelize/issues/7310

[Restuta]

This TL;DR should be in the original description, saves so much time @krishangupta

[bradennapier]

As far as I can tell, all this information is incorrect now?

1. Settings operatorsAliases to false produces an error that it is a no-op

(node:23934) [SEQUELIZE0004] DeprecationWarning: A boolean value was passed to options.operatorsAliases. This is a no-op with v5 and should be removed.

1. Settings operatorsAliases to the recommended for aliasing will still produce a warning (as shown in documentation)

const Op = Sequelize.Op;
const operatorsAliases = {
  $eq: Op.eq,
  $ne: Op.ne,
  $gte: Op.gte,
  $gt: Op.gt,
  $lte: Op.lte,
  $lt: Op.lt,
  $not: Op.not,
  $in: Op.in,
  $notIn: Op.notIn,
  $is: Op.is,
  $like: Op.like,
  $notLike: Op.notLike,
  $iLike: Op.iLike,
  $notILike: Op.notILike,
  $regexp: Op.regexp,
  $notRegexp: Op.notRegexp,
  $iRegexp: Op.iRegexp,
  $notIRegexp: Op.notIRegexp,
  $between: Op.between,
  $notBetween: Op.notBetween,
  $overlap: Op.overlap,
  $contains: Op.contains,
  $contained: Op.contained,
  $adjacent: Op.adjacent,
  $strictLeft: Op.strictLeft,
  $strictRight: Op.strictRight,
  $noExtendRight: Op.noExtendRight,
  $noExtendLeft: Op.noExtendLeft,
  $and: Op.and,
  $or: Op.or,
  $any: Op.any,
  $all: Op.all,
  $values: Op.values,
  $col: Op.col
};

const connection = new Sequelize(db, user, pass, { operatorsAliases });

Will produce the warning

(node:23711) [SEQUELIZE0003] DeprecationWarning: String based operators are deprecated. Please use Symbol based operators for better security, read more at http://docs.sequelizejs.com/manual/querying.html#operators

even though the linked docs clearly indicate:

Sequelize will warn you if you're using the default aliases and not limiting them if you want to keep using all default aliases (excluding legacy ones) without the warning you can pass the following operatorsAliases option -

A bit of a mess here, understandable its a bit of a confusing transition but sucks there seems to be no way to transition smoothly without those warnings showing up everywhere and worrying various engineers when they run into it.

In our case, we have a lib that handles Sequelize versions 3-5 as we transition libraries to use the latest. It appears impossible at this point to not get warnings on all our applications.

---

This may be due to v5 being used in this test scenario, but the documentation for v5 should then reflect that this option is no longer allowed in any way and the warning will always show if that option is ever defined at all.

[SystemDisc]

@bradennapier This thread relates to v4. In v4, set operatorsAliases to false. In v5, do not set operatorsAliases unless you have a very specific use case and you understand the original vulnerability: https://github.com/sequelize/sequelize/issues/7310

Please, would you mind removing the snippet you posted regarding setting up string-based operators? I feel it will confuse new users to sequelize and/or users who have not seen this thread before. In your second bullet, where you use the word "recommended", it is very misleading. Everyone is strongly urged to NOT use string-based operators and to not define their own aliases - it'll be safer for you, especially if you do not fully understand the original vulnerability or how operatorsAliases works.

By the way, "This is a no-op with v5 and should be removed." has the same meaning as the sentence "This does nothing in v5 and should be removed."

To anyone confused, please read this TL;DR: https://github.com/sequelize/sequelize/issues/8417#issuecomment-461150731
I've updated that post to include information regarding v5.

[plinioaltoe]

I just did this: operatorsAliases: "false"

Put "false" as string and not bool. It worked for me

[SystemDisc]

@plinioaltoe You should be setting operatorsAliases: false (boolean false) in v4 and not setting it at all in v5+

[eoknait]

I did everything according to the instructions and I have a 404 error. I downloaded the project from github, I also have a 404 error for each address. only localhost: 3000,

Express works

Welcome to Express

[dehypnosis]

For my system, query payloads with complex operators are transferred from my internal services which means payloads are serialized as text based packet and then unserialized again to JSON which will be parsed as sequelize find options / where attribute.

So I really need this string based operator aliases feature. And hope this feature shall not be deprecated.. ever. I really don't wanna dig into complex payload and map string aliases to symbol operators.

Also I cannot turn this deprecation warning off.
For now.. for someone like me.

// tslint:disable-next-line:no-var-requires
require("sequelize/lib/utils/deprecations").noStringOperators = () => {};

[francodoshii]

I tried to use

const Op = Sequelize.Op;
const operatorsAliases = {...}

following this http://docs.sequelizejs.com/manual/tutorial/querying.html#operators-aliases
However I got error:
Invalid value [object Object]
when this code below run:

let options = {where: {}, raw: true};
...
options.where.name = {$ilike: `%${filters.name}%`};
options.where.duration = filters.duration;
...
Banners.findAndCountAll(options);

Before update operatorsAliases, everything works fine.
How can I fix this?

Experiencing the same issue, were you able to solve this?

[francodoshii]

experiencing this issue at 5.18.4

[francodoshii]

Assigned operatorsAliases with an empty array [] to not trigger the warning. We are not using operatorsAliases, will this cause an issue?
The above assignment will result to this.OperatorsAliasMap = false.

setOperatorsAliases(aliases) { if (!aliases || _.isEmpty(aliases)) { this.OperatorsAliasMap = false; } else { this.OperatorsAliasMap = Object.assign({}, aliases); } }

[francodoshii]

As far as I can tell, all this information is incorrect now?

1. Settings operatorsAliases to false produces an error that it is a no-op

(node:23934) [SEQUELIZE0004] DeprecationWarning: A boolean value was passed to options.operatorsAliases. This is a no-op with v5 and should be removed.

1. Settings operatorsAliases to the recommended for aliasing will still produce a warning (as shown in documentation)

const Op = Sequelize.Op;
const operatorsAliases = {
  $eq: Op.eq,
  $ne: Op.ne,
  $gte: Op.gte,
  $gt: Op.gt,
  $lte: Op.lte,
  $lt: Op.lt,
  $not: Op.not,
  $in: Op.in,
  $notIn: Op.notIn,
  $is: Op.is,
  $like: Op.like,
  $notLike: Op.notLike,
  $iLike: Op.iLike,
  $notILike: Op.notILike,
  $regexp: Op.regexp,
  $notRegexp: Op.notRegexp,
  $iRegexp: Op.iRegexp,
  $notIRegexp: Op.notIRegexp,
  $between: Op.between,
  $notBetween: Op.notBetween,
  $overlap: Op.overlap,
  $contains: Op.contains,
  $contained: Op.contained,
  $adjacent: Op.adjacent,
  $strictLeft: Op.strictLeft,
  $strictRight: Op.strictRight,
  $noExtendRight: Op.noExtendRight,
  $noExtendLeft: Op.noExtendLeft,
  $and: Op.and,
  $or: Op.or,
  $any: Op.any,
  $all: Op.all,
  $values: Op.values,
  $col: Op.col
};

const connection = new Sequelize(db, user, pass, { operatorsAliases });

Will produce the warning

(node:23711) [SEQUELIZE0003] DeprecationWarning: String based operators are deprecated. Please use Symbol based operators for better security, read more at http://docs.sequelizejs.com/manual/querying.html#operators

even though the linked docs clearly indicate:

Sequelize will warn you if you're using the default aliases and not limiting them if you want to keep using all default aliases (excluding legacy ones) without the warning you can pass the following operatorsAliases option -

A bit of a mess here, understandable its a bit of a confusing transition but sucks there seems to be no way to transition smoothly without those warnings showing up everywhere and worrying various engineers when they run into it.

In our case, we have a lib that handles Sequelize versions 3-5 as we transition libraries to use the latest. It appears impossible at this point to not get warnings on all our applications.

This may be due to v5 being used in this test scenario, but the documentation for v5 should then reflect that this option is no longer allowed in any way and the warning will always show if that option is ever defined at all.

Check out my reply above. I hope it helps. If you find my workaround to be incorrect, enlighten me, thank you.

[atmanandsah]

Since I upgraded to 4.13.2 I get a deprecation warning

sequelize deprecated String based operators are now deprecated. Please use Symbol based operators for better security, read more at http://docs.sequelizejs.com/manual/tutorial/querying.html#operators node_modules/sequelize/lib/sequelize.js:236:13

I do not use any string based operators, however, or any operators of any kind. I didn't even know what an operator was actually, which is why I was confused.

I can fix this by adding operatorsAliases: false when instantiating the Sequellize object as below. Should this not be the default though? Or can we have the warning and documentation more clearly state that operatorsAliases: false must be set in order to avoid the warning?

const sequelize = new Sequelize(
  config.RDS_DB_NAME,
  config.RDS_USERNAME, 
  config.RDS_PASSWORD,
  {
    host: config.RDS_HOSTNAME,
    dialect: 'mysql',
    logging: false,
    freezeTableName: true,
    operatorsAliases: false
  }
)

but can you explain why we are using operatorsAliases: false

[emarcelino3]

I'm in Sequelize 5.21.8 version. Same issue here.

With operatorsAliases like:

const operatorsAliases = { 
  $eq: Op.eq,
  $ne: Op.ne,
  ...

It's working fine : where: {id_ativo: { [Op.notIn] : arr }
ok

It's working fine : where: {id_ativo: { $notIn : arr } (
But warning: [SEQUELIZE0003] DeprecationWarning:

Without operatorsAliases :
Anything works using operators

What am I doing wrong?

[ninsun]

What should I do if I did not use operatorsAliases and want to filter the result using where but only can done by JSON? Like in a restful api? I parse the JSON to object by my self?
I mean, how can I use Op.gt when I can only use json, something like {"where": {"start_datetime": {"$gt": "2020-11-25"}}} ?