SES: Why do the mitigation options have two different sets of defaults?

17 views
Skip to first unread message

Kevin Reid

unread,
Jun 19, 2015, 6:02:38 PM6/19/15
to Google Caja Discuss
In startSES.js, we have the following function which normalizes the mitigation options. If it is passed null/undefined, parseFunctionBody will be true, but if it is passed {}, parseFunctionBody will be false. Why?

The context of this question is that I was considering using the sourceUrl option where it was not previously present, and doing so will currently change other behavior unless I override that option.

  function resolveOptions(opt_mitigateOpts) {
    function resolve(opt, defaultOption) {
      return (opt_mitigateOpts && opt in opt_mitigateOpts) ?
        opt_mitigateOpts[opt] : defaultOption;
    }
    var options = {};
    if (opt_mitigateOpts === undefined || opt_mitigateOpts === null) {
      options.maskReferenceError = true;
      options.parseFunctionBody = true;
      options.sourceUrl = void 0;

      options.rewriteTopLevelVars = true;
      options.rewriteTopLevelFuncs = true;
      options.rewriteFunctionCalls = true;
      options.rewriteTypeOf = false;
      options.forceParseAndRender = false;
    } else {
      options.maskReferenceError = resolve('maskReferenceError', true);
      options.parseFunctionBody = resolve('parseFunctionBody', false);
      options.sourceUrl = resolve('sourceUrl', void 0);

      options.rewriteTopLevelVars = resolve('rewriteTopLevelVars', true);
      options.rewriteTopLevelFuncs = resolve('rewriteTopLevelFuncs', true);
      options.rewriteFunctionCalls = resolve('rewriteFunctionCalls', true);
      options.rewriteTypeOf = resolve('rewriteTypeOf',
                                      !options.maskReferenceError);
      options.forceParseAndRender = resolve('forceParseAndRender', false);
    }
    return options;
  }

Mark Miller

unread,
Jun 21, 2015, 7:04:07 PM6/21/15
to Google Caja Discuss
On Fri, Jun 19, 2015 at 3:02 PM, 'Kevin Reid' via Google Caja Discuss <google-ca...@googlegroups.com> wrote:
In startSES.js, we have the following function which normalizes the mitigation options. If it is passed null/undefined, parseFunctionBody will be true, but if it is passed {}, parseFunctionBody will be false. Why?

The text in startSES (which I think I wrote) says:

        If {@code opt_mitigateOpts} is {@code undefined ||
        null} then all default transformations are applied

which implies that these should be the same. I see from the code below that the null/undefined settings differ from the fully default settings only for parseFunctionBody. I see no mention of parseFunctionBody in either code or comments that would explain a rationale for having these differ. If I in fact wrote these to differ (as I think I did) I did not write down anything that reminds me of why, and I cannot currently construct a reason.

I think it should default to false in both cases. Also we should refactor this code so these decisions are expressed only once. That way they are less likely to get out of sync.
-- 
  Cheers,
  --MarkM

Kevin Reid

unread,
Jul 27, 2015, 1:11:49 PM7/27/15
to Google Caja Discuss
On Sun, Jun 21, 2015 at 4:03 PM, Mark Miller <eri...@gmail.com> wrote:
On Fri, Jun 19, 2015 at 3:02 PM, 'Kevin Reid' via Google Caja Discuss <google-ca...@googlegroups.com> wrote:
In startSES.js, we have the following function which normalizes the mitigation options. If it is passed null/undefined, parseFunctionBody will be true, but if it is passed {}, parseFunctionBody will be false. Why?

I think it should default to false in both cases. Also we should refactor this code so these decisions are expressed only once. That way they are less likely to get out of sync.
Reply all
Reply to author
Forward
0 new messages