Today when i rescanned veracode reopened a bunch of lines with things like...
$(document).off('click.applicationmenu open-applicationmenu close-applicationmenu keydown.applicationmenu');
$(document).on('open-applicationmenu', () => {...
$(document).trigger($.Event('keydown', { keyCode: 27, which: 27 }));
Why is $(document) considered a "Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS" flaw ? And also why suddenly today and never before on any other scans.
This seems like it would be fine to me or how to fix/mitagate if its not?
Turns out this was something they added and removed to the scan results. It does not seem to be reported anymore.
Related
So I have this fake object definition, that has a fake method in it :
// Note: This is a simplified version of my code.
// If it turns out that such issues could come from complex method prototypes,
// then I'll post the full setup.
IFooRepositoryClass fooRepo = A.Fake<IFooRepositoryClass>();
A.CallTo(() => fooRepo.FooFunctionAsync(A<Guid>.Ignored).ReturnsLazily(
(Guid fooId) => {
fooInternalObject.DoSomething(fooId);
}
);
As you can see, nothing out of the ordinary.
Later, in my XUnit tests, I call the fake function :
Guid testGuid = new Guid("aaaaaaaa-9a88-4746-914b-aaaaaaaaaaaa"); //I changed to "aaaaa" to make it easily recognizable
await fooRepo.FooFunctionAsync(testGuid).configureAwait(false);
I put a breakpoint on that instruction :
await fooRepo.FooFunctionAsync(testGuid).configureAwait(false);
...I see that testGuid is indeed aaaaaaaa-9a88-4746-914b-aaaaaaaaaaaa
But then I put a breakpoint inside, on this instruction :
fooInternalObject.DoSomething(fooId);
To my great surprise, fooId has a weird value with lots of zeros, different at each run!
f933b838-007b-0000-0000-000000000000
785bb288-001a-0000-0000-000000000000
4d4bb8d8-0012-0000-0000-000000000000
etc.
As you can see it's not Guid.Empty, just Guids that look suspiciously manufactured.
What the hell is going on? Can FakeItEasy do that to Guids?
Even weirder : I shared my branch to a colleague, and he checked it out. So he has the exact same code as me.
...But for him, fooId has the expected value, i.e. the value of testGuid! We peeked at each other's screen and every execution conditions seem identical. Only the Guid differs at the breakpoint : Expected value for him, bogus values for me. I cleaned the solution, rebuilt, even restarted VS. to no avail!
What the hell is going on? x2
I'm not expecting anyone to fix my unit tests, but maybe this is a well-known behaviour under certain conditions. Ever seen that? Especially those weird 000000 Guid values? Something has to differ between our setups, but I need a lead to know where to look.
It appears that XCtest "self measureBlock" is limited to milliseconds and 10 runs of the test code. Are there any ways to modify the behavior of measureBlock for more runs and/or nano or microsecond accuracy?
TL;DR
Apple provides a way to modify the behavior of measureBlock: by providing extra string constants but they don't support any string constants other than the default.
Long explanation
measureBlock calls the following function
- (void)measureMetrics:(NSArray *)metrics automaticallyStartMeasuring:(BOOL)automaticallyStartMeasuring withBlock:(void (^)(void))block;
//The implementation looks something like this (I can't say 100% but i'm pretty sure):
- (void)measureBlock:(void (^)(void))block {
NSArray<NSString *> *metrics = [[self class] defaultPerformanceMetrics];
[self measureMetrics:metrics automaticallyStartMeasure:YES withBlock:block];
}
defaultPerformanceMetrics is a class function that returns an array of strings.
From the Xcode source
"Subclasses can override this to change the behavior of
-measureBlock:"
Lovely, that sounds promising; we have customization behavior right? Well, they don't give you any strings to return. The default is XCTPerformanceMetric_WallClockTime ("com.apple.XCTPerformanceMetric_WallClockTime")
It turns out there aren't any string constants to return besides that one.
See the slides for WWDC 2014 Session 414 Testing in Xcode 6 (link).
I quote from page 158:
Currently supports one metric: XCTPerformanceMetric_WallClockTime
Nothing else has been added in Xcode 7 so it seems you're out of luck trying to modify measureBlock, sorry.
I've never found measureBlock: very useful. Check out Tidbits.xcodeproj/TidbitsTestBase/TBTestHelpers/comparePerformance https://github.com/tipbit/tidbits if you'd like to look at an alternative.
I am using the webshims library to support older browsers better with more modern features. While the date picker works great with the mouse I seem to be having problems using it from the keyboard. The easiest way to see this is visit the demo page. I am using Firefox since it doesn't have date support.
Without making any modifications try to type in a date. I can enter numbers but I cannot enter a "/". If you enable the placeholder it even suggests the slash. I tried leaving out the separator or using "-" (which it lets me type) but when the form submits I get no value.
How are you supposed to enter a date via the keyboard?
For bonus points is it possible to allow the date picker to not enforce a format? I have backend code that can parse a wide variety of date formats. So they can use the date picker if they wish but if they type something in then whatever they type in is sent onto the server without modification.
Try this.This works for '/' format..
$.webshims.formcfg = {
en: {
dFormat: '/',
dateSigns: '/',
patterns: {
d: "mm/dd/yy"
}
}
};
webshims.activeLang('en');
It appears that there is an issue with the locale settings. From what I can tell, there is a form config attribute called dateSigns that gets set in the locale settings.
The solution for me was to go to file shims/combos/5.js and look for a chunk of code having dateSigns in it. I found the relevant one for US English around line 1750, which looks like this:
if(!formcfg['en-US']){
formcfg['en-US'] = $.extend(true, {}, formcfg.en, {
date: {firstDay: 0},
patterns: {d: "mm/dd/yy"},
dateSigns: '-',
dFormat: "/",
meridian: ['AM', 'PM']
});
}
I updated the dateSigns line to
dateSigns: '/',
It is a horrible hack, and there must be a way to set this as a configuration, or at least get the real locale settings to handle this. But I didn't manage to in the limited time I have available. But maybe this will help you. It works for me.
I am crossfading some audio and I have a equal power curve stored in a table. I'm calling this function to start the fadeout. The fade parameter is a GainNode made with createGain()
fade.gain.setValueCurveAtTime(epCurveOut, context.currentTime, fadeTime);
In Chrome and Safari all goes well, but Firefox (v30) complains:
SyntaxError: An invalid or illegal string was specified
Instead of context.currentTime I've tried 0 and 0.01. Is this method not implemented maybe? If so how would I alternatively schedule a cosine equal power ramp over time?
This seems to be a bug on our end indeed, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1069825 to track this.
Firefox seems to give that error whenever it doesn't like the parameters to setValueCurveAtTime. For example, if epCurveOut is an empty Float32Array, or if there is already a parameter change scheduled at the same time. I suspect the latter, because Chrome doesn't throw an error under the same circumstances. For example:
curve = new Float32Array([0.5, 0.5]);
node.gain.setValueCurveAtTime(curve, 5, 1);
node.gain.setValueCurveAtTime(curve, 5, 1);
Firefox throws the error the second time. Chrome doesn't throw an error. If you call node.gain.cancelScheduledValues(5) in between the calls to setValueCurveAtTime, Firefox allows it.
EDIT: Oh, hmm, Chrome doesn't complain about an empty Float32Array either. Well, anyway, Firefox seems to be much less forgiving, and gives that error when the arguments' types are correct but the values aren't allowed.
I finally got this plugin to work with IE9 in compatibility mode only to realize that its only filtering by 'starts with' ... has anyone implemented or knows how to make this thing work with a 'contains' search instead?
Chosen now supports this directly as an option:
$(".chzn-select").chosen({ search_contains: true });
From 'pfiller' on the Chosen issues forum:
Chosen doesn't support it by default, but it is a relatively minor change. Just remove the ^ from the following line:
regex = new RegExp('^' + searchText.replace(/[-[\]{}()*+?.,\\^$|#\s]/g, "\\$&"), 'i')
Should look like this now:
regex = new RegExp(searchText.replace(/[-[\]{}()*+?.,\\^$|#\s]/g, "\\$&"), 'i')