We Keep Coding

Fetching tokens present in javascript file

I'm writing some client side javascript code that we expect to be reverse engineered at some point. I want a way that we can say with a reasonable degree of certainty that we are not exposing any debug information. We are running the code through uglify, so it obfuscates the variable names.
My thought was to fetch all the string literals (and tokens?) from the file and match them using a jest snapshot, but I can't find a tool that will pull the information from the JS file. Does anyone have any experience doing this?
Update:
I think it would help if I gave an example
Suppose someone were to write this code:
function processSensitiveData () {
console.log('processing sensitive data')
doMoreThings();
}
processSensitiveData();
There is nothing wrong with that because we strip console.log statements in production, and uglify transforms the function name, so no sensitive information is present. Suppose someone were to modify it to this code:
function processData (dataType) {
console.log('processing ' + dataType + ' data');
doMoreThings();
}
processData('sensitive');
Now, while the console.log statement gets stripped out, 'sensitive' will still be in the final output. It's this kind of thing that we want to avoid. While code reviews are the first line of defense, this is very likely to be missed in a code review, especially if combined with other changes. I'd like to have the computer do it, as that is something that a computer would do much better than a human. Ideally, it would be a linting rule, but that would be a very complicated rule to write.

Code reviews. This way if you review any and all code checked into source you will be aware if there is debugging information that is trying to sneak its way into your repo. Besides that you can keyword search before deployment as well for 'alert', 'debug' and other debugging JavaScript keywords.

Grunt pid files and Grunt-kill

Trying to use grunt-kill to create a task that will kill my server-scorm task, and eventually any related tasks. The instructions are extremely short because it assumes I know all about PID files (which I don't, not the devs fault) and Grunt Manual makes 0 reference to them.
The problem is that I don't know how to properly reference the PID file path and what naming scheme Grunt uses.
I can get the the IDs when I run the following command:
ps aux | grep grunt
But of course that does me no good when the PID changes every time, so I can't directly reference it.
The instructions say to put this in the config:
kill: {
myService: {
src: [ 'my-service.pid' ]
},
secondary: {
pid: 'secondary.pid'
}
}
This is one example of how to use it... but ['my-service.pid']I have no idea how to get to that.
In my case, the name of the command grunt task I'm trying to kill is server-scorm so I assumed it was:
kill: {
serverScorm: {
src: [ 'server-scorm.pid' ]
},
}
of course when I run it, it doesn't recognize it. I get this:
seems that the missing piece to this puzzle is that I can't get to the server-scorm.pid or what ever its called.
If you're wondering why I'm not using cntrl+c it's the team is using an IDE called brackets and it "nicely" provides a grunt interface where all you have to do is click a button and it will run a command... As you may have guessed, there is no place where you can input commands like that.

I am copying my answer from your bug report on GitHub.
Hi #phillt The grunt-kill plugin cannot natively determine the pid for any process because without a pid, how would it know which process you want? Each application's way of "discovering" it could be different, and it could even be running multiple processes.
There are two ways for this plugin to determine the pid:
Specify the pid file. This requires the process you are attempting to kill to write its pid to a file. This is a common pattern for daemons in Unix, particularly when they run in the background as a service. The approach is when starting up, they write the PID of the main process that should be killed into a file in a well-known location and then tools like grunt-kill can read that file and know which process to kill. For example, the Apache web server on RedHat typically writes its pid file to something like /var/run/httpd.pid. I am not familiar with server-scorm, so cannot say for sure if it uses a pid file.
Specify the PID itself or a function which returns the PID. If you have a way to reliably find the PID programmatically, you can write it as a function in your Gruntfile and grunt-kill will happily execute it to discover the PID. You can probably put some filters around ps aux to find the pid. Maybe filter by process name and user login name?
On a side-note, I work in the e-learning space, so server-scorm and the adapt framework is going to give me some homework. :)

Getting 'unexpected mongo exit code 100' while running a meteor application

I am new to meteor .I started learning meteor language by referring a book
'My First Meteor Application'...While i was running my application i am getting a 'unexpected mongo exit code 100' error.It is showing 'unexpected mongo exit code 100 restarting'.help me get over this error

This error indicates that either mongo process is still running in the background or it was killed improperly. You may use
try `ps -A | grep 'mongo'
to see what's going on. Either way, in your .meteor/local/db directory, there will be a non-empty mongo.lock file. If there's an active mongo process, kill it and the file should become empty. Otherwise remove the file manually. When you're done the error should disappear.

This seems to be a common problem and there are multiple similar questions already out there with just as many suggested fixes. Problem is some of the proposed fixes either only work in certain cases or require using the meteor reset command which deletes the apps database(not ideal for everyone). I posted practically the same question a while back. I managed to solve it in my case and posted my answer to my own question here. It seems to have fixed the issue for several people already without the need for meteor reset so it's worth a try if you haven't found a fix yet. Good luck!

Sails.js with skipper: check if file input were empty before starting upload

I'm using Sails 11.1 and skipper 0.5.5.
I have a form to create an article in my app. An image can be attached to an article, so there is an input file.
I would like to check, server-side, if this input file was empty, before trying to start upload.
Is it possible, and if yes, how can I do this?
I tried to check req.files, or req.files.photo ("photo" is the input name) and req.body.photo, but they are always undefined, even if there is a file.
req.file('photo') is always defined, so I can't check it.
Just a note: when the input is filled with a file, the upload works.
Thanks in advance.
PS: this question can also be found here, on the skipper GitHub issues.

The only working solution I found while working on this a few weeks back was to upload the file(s) and then see if any file had been uploaded.
req.file(inputname).upload({
dirname: targetLocation,
maxBytes: 2*1024*1024
},
function (err, uploadedFiles) {
// do stuff with uploadedFiles
});
I'm not sure why your req.file(inputname) returns null even when a file is uploaded.
Importantly, note that calling req.file() is tricky. I had used it to determine the file size, extension and so on initially. Seemed like a good way to avoid uploading anything at all if it were irrelevant. However, if you don't follow that call with an upload() call in 4.5 seconds (default), Node crashes with an ETIMEDOUT error. I had a hard time figuring that out and haven't complained about the above method ever since.

Simogeo FileManager View/Upload

I've tried to set up Simogeo's FileManager but I can only get half of it working.
My plan is to set it to a specific folder (../imgs/gallery) and allow the client to upload, download, rename, remove files - basically change the ones displayed on a specific page (../gallery.html).
Right now though, I can't get the FileManager to work properly. In it's absolutely simplest form (that is, uploading the extracted files to my /www/ root and duplicating filemanager.config.js.default to filemanager.config.js) it will allow me to create a folder and upload files but the second I do that, it'll just keep 'loading' something. Nothing shows, nothing is usable and a refresh will completely remove it from view.
The files are being created/uploaded in the ../userfiles/ folder which I can change in the future but it's just not working even in a pure setting.
(also, the instructions request changing a file ../connectors/php/filemanager.config.php, which for the life of me, I cannot find. ../connectors/php/default.config.php exists but doesn't follow the instructions very well if I was to substitute that.)
EDIT: I tried the 0.8 version, having no problems. It's a shame the up-to-date one doesn't work for me.

Are you sure permissions are set correctly on your folder ?
You could try :
chmod -R 0777 /path/to/filemanager/userfiles/
or (asserting you're running apache with www-data user :
chown -R www-data:www-data /path/to/filemanager/
You may also have a look to the configuration wiki page and sample page.
(also, the instructions request changing a file ../connectors/php/filemanager.config.php, which for the life of me, I cannot find. ../connectors/php/default.config.php exists but doesn't follow the instructions very well if I was to substitute that.)
Thanks for pointing this out. It is updated.

In my case the problem arose when migrating a site from dedicated hosting with PHP 5.3 to shared hosting with PHP 5.4, all of a sudden the file manager started behaving as described by the original poster. I updated to the latest FileManger version (2.0.0-dev) but still the same.
A look at the server error log showed a fatal error in connectors/php/filemanager.class.php on line #1312 where require_once('./inc/vendor/wideimage/lib/WideImage.php') failed to open the file. Checking the path there is no "vendor" directory so I removed that from the path and the server error went away. But still the same loading graphic.
I then considered that PHP 5.4.x wants to have the TimeZone set and depending on the server configuration may throw warnings or errors, even fatal ones in the background. So I added date_default_timezone_set ('America/Toronto'); at the top of the file connectors/php/filemanager.php and after that everything worked perfect. This may not be the optimal solution but it worked for me. If you try it of course change the TimeZone to your own.
This one had me pulling my hair out for a while, hope it helps someone.