I want to be able to get the checksum of a chrome extension and match that against the source code in a reliable way? the optimal way would be if a checksum is exposed through chrome apis without having to read the files.
I have searched hard for this and it seems that there is no reliable way, but i wanted to see if others have different ideas. Here are things that i considered:
I have got an extension with both the source code, and the extension files in chrome, i have found that after comparing both directories that manifest.json got its styling changed: indention and order of properties, and one icon was modified - probably compressed. means even after reading files content this is not reliable.
The chrome folder has a metadata folder which has hashes used to ensure the files are not modified on disks, however using these hashes is also not reliable, since these hashes are probably after the modifications mentioned above, and also there is no mention in the documentation about how these hashes are calculated, and so they can change without a prior notice.
Related
Ive been looking on the the internet for answer but none comes close to what i was looking for. What is the folder for?
and inside is this json file:
What happen if i delete the folder and do i really need that to be in the folder? Thank you
Short answer:
If you delete it, probably nothing much bad will happen. It'll probably get created again. Your live server may or may not end up on the same port. Probably don't commit it to source control (but maybe you want to).
Longer answer:
.vscode as a folder name has a few clues:
the leading . kind of means "hide this folder". It comes from *nix operating systems where by default if you name a file or folder .anything it'll get hidden.
being called .vscode, which is the name of the editor you're using, suggests it relates specifically to using vscode.
The fact that it gets created when you "do something" suggests that it'll cope if it's not there, but probably the way it'll cope is to re-create it. That's a pretty common thing too.
One use for a settings.json file in a folder is for settings that are specific to that folder. Often you'd have settings that you want to apply to vscode wherever you're using it. But sometimes you have settings that apply to a specific bit of code.
The people that wrote the LiveServer extension seem to think that what port the live server runs on is one of those "per project" settings. I'd agree. You may want to run 2 or 3 live servers (e.g. a PHP web-site and another one that just does API, maybe), or the port that they chose might be in use by something completely else. So to deal with that, they create this settings file. I'd take a stab that if you edit that, then the LiveServer is going to show up on a different port.
But you can probably find the code and check it. Probably this document will tell you what to know.
https://github.com/ritwickdey/vscode-live-server/blob/HEAD/docs/settings.md
(A possibility here that I've chosen the wrong extension, but most vscode extensions are open source, so you should be able to follow the trail to a github repo, and then to either some docs or some code).
Editor settings are that border-line with source control - whether to check in or not. Lots of projects have defined editor settings, such as tabs vs spaces or linting engines. Lots don't. Possibly in this case, if you're part of a large project, the specific ports to use are defined, so it'd go into source control. If it's just you, do what feels good.
I'm using VS code (v1.74.3),Live Server (v5.7.9). There is no settings.json in .vscode folder of my JS project. Instead the settings.json is created in the folder "C:\Users\USER NAME\AppData\Roaming\Code\User" and it is a global settings file to specify extension properties. Most of the Live Server configuration settings mentioned in the documentation can be applied at global level.
Note: this is not a dupe of this or this other question. Read on: this question is specific to the Code-Sharing template.
I am doing some pretty basic experiments with NativeScript, Angular and the code sharing templates (see: #nativescript/schematics).
Now I am doing some exploration / poc work on how different "build configuration" are supported by the framework. To be clear, I am searching for a simple -and hopefully official- way to have the application use a different version of a specific file (let's call it configuration.ts) based on the current platform (web/ios/android) and environment (development/production/staging?).
Doing the first part is obviously trivial - after all that is the prime purpose of the code sharing schematics. So, different versions of the same file are identified by different extensions. This page explain things pretty simply.
What I don't get as easily is if the framework/template supports any similar convention-based rule that can be used to switch between debug/release (or even better development/staging/production) versions of a file. Think for example of a config.ts file that contains different parameters based on the environment.
I have done some research in the topic, but I was unable to find a conclusive answer:
the old and now retired documentation for the appbuilder platform mentions a (.debug. and .release.) naming convention for files. I don't think this work anymore.
other sources mention passing parameters during the call to tns build / tns run and then fetching them via webpack env variable... See here. This may work, but seems oddly convoluted
third option that gets mentioned is to use hooks to customize the build (or use a plugin that should do the same)
lastly, for some odd reason, the #nativescript/schematics seems to generate a default project that contains two files called environment.ts and environment.prod.ts. I suspect those only work for the web version of the project (read: ng serve) - I wasn't able to get the mobile compiler to recognize files that end with debug.ts, prod.ts or release.ts
While it may be possible that what I am trying to do isn't just supported (yet?), the general confusion an dissenting opinions on the matter make me think I may be missing something.. somewhere.
In case this IS somehow supported, I also wonder how it may integrate with the NativeScript Sidekick app that is often suggested as a tool to ease the build/run process of NativeScript applications (there is no way to specify additional parameters for the tns commands that the Sidekick automates, the only options available are switching between debug/release mode), but this is probably better to be left for another question.
Environment files are not yet supported, passing environment variables from build command could be the viable solution for now.
But of course, you may write your own schematics if you like immediate support for environment files.
I did not look into sharing environment files between web and mobile yet - I do like Manoj's suggestion regarding modifying the schematics, but I'll have to cross that bridge when I get there I guess. I might have an answer to your second question regarding Sidekick. The latest version does support "Webpack" build option which seems to pass the --bundle parameter to tns. The caveat is that this option seems to be more sensitive to typescript errors, even relatively benign ones, so you have to be careful and make sure to fix them all prior to building. In my case I had to lock the version of #types/jasmine in package.json to "2.8.6" in order to avoid some incompatibility between that and the version of typescript that Sidekick's cloud solution is using. Another hint is to check "Clean Build" after npm dependency changes are made. Good luck!
I'm using primefaces and primefaces-extensions in my application. For each and every resources like .css and .js files there's also an "ln" and "v" query parameters in the GET request for that resource, like below:
primefaces-extensions.js?ln=primefaces-extension&v=6.1
validation.js?ln=primefaces&v=6.1
As a security concern, since these parameters shows the exact version of the framework I'm using, how can I hide them?
Hiding the 'ln' is kind of useless since with a very small amount of effort, you can get the same information from the javascript files and the source of the page too ('PF() is all over the place)
The 'v' however is a slightly different issue. If you use the non-modified PF source, hiding it is sort of useless too since with very little effort (creating a hash) the possible hackers can download your sources, create a hash and compare the resulting hashes with a dictionary they can easily create of existing PrimeFaces sources and then know which version you use. So the only thing to do here is to modify the source to have it not turn up 'known or comparable' hashes by making some slight modifications (adding whitespace should already help).
But if you really want the version not to be show, you can download the PrimeFaces sources and replace the version info with some ofuscated number and build that custom version. Keep in mind that if you don't make any changes in the sources, the dictionary lookups mentioned above are still working. So it is only some minor inconvenince for hackers.
I am using PhpStorm for few months now and I have just noticed something really weird about language injections in the version 9.0.
Sometimes I have to declare that some strings in my PHP are Javascript instructions. When I do so and save my file (with auto-upload on), it looks like PhpStorm is doing a lot of remote checks, file moves and transfers, I dont really understand why... and I'm afraid that it may overwrite files that I didn't modifie. I'm working directly on a production server with other people, I know it's dangerous but we have no choice for the moment.
In the file transfer logs, I have something like that :
[18/09/2015 10:47] Automatic upload completed in less than a minute: 2 items deleted, 50 items moved, 4 files transferred (4 Kb/s)
Can someone help understand what is going on ?
I have found a way to do what I want, but didn't find the reason of theses uploads that PhpStorm does without asking anything...
The problem is that, until now, I didn't found a way to save files one by one. It looks like PhpStorm has only a "Save all" option that uploads every files changed since last save (if you ask for auto-upload). And in the case of a language injection PhpStorm seems to change a something in the opened files that forces it re-upload them all.
So I disabled auto-upload and bound a shortcut to "Upload to default server". This option uploads only your current file but it saves it before. So it's a kind of auto-upload but a little less agressive and it gives me the possibility to just save my files (with "save all") or to save only the current one and upload it instantly.
This is the way I used to work before using PhpStorm, I find it more convenient and less violent than this automatic upload process that Phpstorm uses.
If someones find something better I'm opened to any advice.
I don't want to use expiration, because I don't know how often my resources (css, js, etc) will change. A case might be where I push something to production, but soon find out I have some bugs in the resources. So I fixed the bugs, then push the updated resources into production, but they're in production before the expiration date. How do I force the browser to use the updated resources instead of cache?
I don't want to use fingerprinting (dynamic resource filename based of version type), because those resources are located in an svn directory. Meaning, I would have to manually modify the filename using svn every time I change the code version (maybe there's somewhat to automate this?).
Utilizing http-equiv="last-modified" would be the preferred option, but that doesn't seem to work properly.
Also maybe I just don't know how all this works. Please enlighten me. Many thanks in advance.
-- Tri
One option would be to have all references to those resources to append a version number to the query string or elsewhere in the URL, for example "styles/site.css?version=1.0". That way, since the URL will change during your next release, your browser will see it as a different URL and will not use the file from cache.
If you ever change to using a CDN, deploying all resources to version numbered folders can achieve the same goal.