I recently integrated my error logging with getsentry.com. My problem now it that I had to generate a source map so basically anyone with a modern browser can now see my original code fully commented.
I'm looking for a way to allow access to the source map files to only specific ips and/or subnets with nodejs, since I'm using heroku.
I imagine it will involve using something like https://www.npmjs.org/package/express-ipfilter or https://www.npmjs.org/package/ip. But still trying to think of how to create a middle where to 'route' to the files and evaluate the ips
Related
I'm currently working on a web project(js, html, php with no frameworks) using AWS technology, including AWS version control. I work locally with Xampp and when I push my code to the master branch there is a trigger that deploys the code to the Production environment.
My main problem now is that I need to manually change the development-production urls or use a html tag and relative URLs, and it's a mess.. When working on development my url is something like: "192.168.64.2/web" and when production it's "myweburl.com". So I need something that checks out my actual URL and change all those over the project. Something like a global variable with the URL to use.
I've read about using "dotenv" and "dotenv-webpack" for environment manage, but I do need to install it on the server, as well as nodejs, and configure .gitignore, and I expect an easier solution. I would like to avoid nodejs. I've searched about my question all around internet but I just find ways that do not convince me, but if this question is repeated just redirect me there.
Is there any secure approach just using javascript, php or a config file?
The objective is having something that depending on my URL (DEV, TEST, PROD) changes all the URLs of my project, and protect the other environment URLs from being seen.
Thank you
So I noticed when I ran my react app's production build's login screen from create-react-app that all of the source code for the app was available within the static/js folder. Basically, the code doesn't look any different from the code in my ide, on the production build.
I am wondering if there is a way to hide this behind a login screen? So that a user can't directly access these files unless the login is successful. I have looked around and was unable to find anything of use.
The js files from the production build should be minimized which would look a lot different than in your IDE. I assume what looks "the same" is looking at the source using developer tools. The solution for that is to not deploy the source map files (*.js.map). Those are the files that allow developer tools to transform the minimized code back to its original look.
Removing source maps makes it difficult for someone to learn from the code easily, but if there is sufficient motivation to do so, it can still certainly be reverse-engineered. There are also some parts that wouldn't be obfuscated much at all such as the URLs for API calls which would then give someone a lot more information to use as the basis for hacking attempts.
If you need to prevent seeing any version of the source for people that are not logged in, I would recommend building your app as two apps -- one that just contains the login portion and one with the rest. Code-splitting within one app won't do the trick (at least not without using a solution that is quite a bit more complicated to manage than the two-app option), because it just makes the download process lazy and it is still pretty easy for someone to determine what the other files are and download them. However, even splitting this into two apps only helps if you host the second app differently. This will require server-side protection that only serves the JavaScript files for the second app for a user that is logged in. This means either using a different sub-domain for the second app or at least a different directory on the server that has those protections baked in. How you would implement that protection depends on the details of your authentication approach and the technology stack being used on the server. Most likely, it means using a cookie set by the login process and then having the JS files for the second app served up by something that verifies the cookie before allowing the JS files to be served to the browser.
To overcome displaying your source code in production's build, try to build your app with
GENERATE_SOURCEMAP=false npm run build
I'm trying to figure out how to set up a JavaScript development project that will allow me to factor my code into several files. I plan to run this eventually on a client web browser, but first I need to set up an efficient development environment.
I've used other programming languages before that let you keep a large number of files in a subdirectory and then let you compile everything into your final deployable (or have an interpreter do something similar). Javascript doesn't seem to allow this - I have to manually add a <script> tag for each js file to the head of my web page to get the browser to load it. This can get very hard to manage once you have more than about 10 files that you need to keep track of. It would be nice if I could write <script src="myscripts/**/*.js"> to suck in everything, at least during development time.
I've found Grunt 'uglify' which looks like it would be a handy tool for creating a final file for deployment, but during development I need to keep everything separate so I can debug properly. Is there any way to have my web page load every js file in my development directory?
As others have mentioned in comments, Webpack (or similar) is the way to go. It bundles up all of your relevant code, and can also process it for minification.
I want to address this comment though:
but during development I need to keep everything separate so I can debug properly
You don't need, or want, that. While developing, you want to be testing against the same sort of build process you'll use in a deployment later. So, how can you easily debug your compiled scripts? There's a .map file that gets built, which tells the browser what your original code looked like.
Chrome and other browsers will automatically load and parse this file when you open your developer tools. Then, you'll be able to see the original source code (and in the original language, for anything transpiled) and debug it as if it were not bundled in the first place.
Don't deploy this map file, unless you want external users to be able to see all your original source code.
I'm creating a client based application in HTML Application (HTA) and I would like to know if there's a object persistent library similar to python's shevle that meets the following criteria:
Should be able to read and write on file
Cross browser: should work at least on both HTA and on Firefox (through XULRunner) so that I'll be not tied to any vendor.
Written in JavaScript form
TiddyWiki is able to save itself, regardless of the browser used, though the codes that saves and retrieves files has to be refactored to meet my need.
Well, I wasn't aware that TiddyWiki has a github repository, and they organized the files by module.
I could just take the FileSystem.js file and build a nice api on top of it to simulate shelve functionality.
Trying to see if this is possible -
1.) User logs into our site
2.) Points to a directory
3.) The javascript code reads contents of the directory, shows thumbnails for any jpeg/gif in those directories. This all without uploading all the photos to the server. Kind of a semi desktop app.
Point 3 is something I have never done, is this possible for an online application to do ?
You can't do this...yet (unless you're using a prerelease of Chrome 9). There are some APIs coming down the pike that will make this possible in browsers that support them; there's a description of using them in this article.
But right now, no. To do this, you'll need to use a technology that allows local file access, such as a signed Java applet (normal unsigned ones obviously can't do this) or, on a severely limited number of platforms and browsers, an ActiveX control.
Update: Sorry, the new JavaScript APIs I mentioned above don't give you (user-granted) access to any old directory on their system. They do give you access to the file system, but it's a sandboxed file system. So you'd have to have the users move the files into the sandbox (which you could do via the File API and with drag-and-drop, keeping it an entirely client-side thing, no uploading required). But that isn't quite what you described.
No; this is not possible.
Javascript cannot directly interact with the user's local filesystem
No, it is not possible to access any of the clients files using JavaScript as that would be a security risk.