Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for built in formats in schema files #138

Merged
merged 2 commits into from
Mar 31, 2016

Conversation

hem-brahmbhatt
Copy link
Contributor

Fixed #137

@@ -140,12 +141,13 @@ function normalizeSchema (name, node, props, fullName, env, argv) {
if (BUILT_INS.indexOf(format) >= 0) {
// if the format property is a built-in JavaScript constructor,
// assert that the value is of that type
var Format = typeof format == 'string' ? eval(format) : format;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if eval(format) is the safest, but couldn't find another way...

It means people can inject malicious code via the Format within schemas.

To be honest, if someone has access to schema and config, your app is already pretty compromised...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it suffice to use a simple global name->value map for this, like the following?

BUILT_INS_BY_NAME = {
  'Object': Object,
  'Array': Array,
  'String': String,
 ...
}

var Format = typeof format === 'string' ? BUILTINS_BY_NAME[format] : format

It's more verbose but avoids the need to eval anything.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I prefer that. I wanted to avoid creating a separate object for the sake of a mapping, but it's safer

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 for @rfk's solution. No eval please.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@coveralls
Copy link

Coverage Status

Coverage decreased (-30.8%) to 60.833% when pulling ef85cfb on damnhipster:master into 8444301 on mozilla:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.03%) to 91.667% when pulling bc4bbad on damnhipster:master into 8444301 on mozilla:master.

@@ -13,10 +13,14 @@ describe('convict schema file', function() {
}
});

it('must parse a config specification from a file', function() {
beforeEach(function() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why using a beforeEach? There are cleaner way to test your work I'm sure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code in that existing test was setting up conf, which actually needed to run before the rest of the tests could pass, so I changed it to run within beforeEach rather than relying on a test to run initially for some setup.

The new test I wrote for built-ins in schema files was affecting the rest of the tests by changing the conf. So I made sure that it was done specifically for my test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does mean that if the schema file can't be parsed, it'll fail all tests within schema-tests.js. I can restructure the tests if you think that's a problem not worth introducing.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be great if you could restructure the test. Thanks a lot!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 91.77% when pulling 1b7a110 on damnhipster:master into 8444301 on mozilla:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-30.3%) to 61.317% when pulling 02c31de on damnhipster:master into 8444301 on mozilla:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 91.77% when pulling f571669 on damnhipster:master into 8444301 on mozilla:master.

@madarche madarche merged commit 168755a into mozilla:master Mar 31, 2016
@madarche
Copy link
Collaborator

Thanks a lot for the good work and useful fix @damnhipster!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants