I have the issue I would like to automate via a script so tat .jnlp will be added as an allowable type of file , is there a command like or powershell or regedit that will add it?
The latest file types policies are published in the Chromium source code. You could clearly see that the danger_level of .jnlp type files is DANGEROUS. Therefor Edge will warn users that this file may harm their computers. Let users continue or discard the file.
If you ensure that the content(download file) on the site is safe, you can use this policy to specify the file types that are allowed to be downloaded continuously from a specific site: ExemptDomainFileTypePairsFromFileTypeDownloadWarnings.
Example:
[ { "file_extension": "jnlp", "domains": ["contoso.com"] }, { "file_extension": "exe", "domains": ["contoso.com"] }, { "file_extension": "swf", "domains": ["*"] } ]
If you want to achieve the same function through the registry, you can set it under this path: SOFTWARE\Policies\Microsoft\Edge\ExemptDomainFileTypePairsFromFileTypeDownloadWarnings
Related
I'm using the rollup plugin strip to exclude the console.logs in the production built with following settings
plugins: [
strip({
include: ['**/*.(js|svelte)'],
labels: ['dev'],
functions: ['console.log'],
})
]
I now have the situation that I would like to keep one special log in production. So I created a function in a new file logInProduction.js
export function logInProduction(msg) {
console.log(msg)
throw new Error('PRODUCTION')
}
and added the file to the plugin options by adding this line
exclude: ['logInProduction.js'],
But when calling the function, the error is thrown, so the function was called, but the log before doesn't appear.
Is this because the .js ending is generally included before so the specific exclusion doen't have any effect? Is it possible to do this?
Or is there another maybe better way to keep one specific console.log?
Problem was, that the filename was missing the directory, so
exclude: ['src/utils/logInProduction.js'],
or
exclude: ['**/logInProduction.js'],
does work
I'm trying to translate my company's project from legacy build tool to bazel. Now I'm facing this problem and searched a lot, but unfortunately, I haven't had a clue so far.
Here's the thing:
For compliance with open source audit, we must provide a list of open-source software which are built into our binary. As external dependencies are introduced by repository rules, my intuitive thought is to query these rules and get the URLs. However, subcommand query/cquery hasn't provided such functionality yet AFAIK, it can print rule/target/buildfiles but no repository rules nor their attributes.
Is there a way that I can gather such information from repository rules in WORKSPACE? It's not viable to do it manually as there are thousands of projects in my company and the dependencies also change frequently.
For example, a workspace rule:
http_archive(
name = "testrunner",
urls = ["https://github.com/testrunner/v2.zip"],
sha256 = "..."
)
This dependency is used by a rule named "my_target", so what i expected is that the dependency could be queried like this:
> bazel queryExtDep my_target
External Dependency of my_target: name->testrunner, urls = "https://github.com/testrunner/v2.zip"
--experimental_repository_resolved_file will give you all that information in a single Starlark file, which you can easily process with Starlark or Python etc to extract the information you're looking for.
The resolved file looks something like this:
resolved = [
...,
{
"original_rule_class": "#bazel_tools//tools/build_defs/repo:git.bzl%git_repository",
"original_attributes": {
"name": "com_google_protobuf",
"remote": "https://github.com/google/protobuf",
"branch": "master"
},
"repositories": [
{
"rule_class": "#bazel_tools//tools/build_defs/repo:git.bzl%git_repository",
"attributes": {
"remote": "https://github.com/google/protobuf",
"commit": "78ba021b846e060d5b8f3424259d30a1f3ae4eef",
"shallow_since": "2018-02-07",
"init_submodules": False,
"verbose": False,
"strip_prefix": "",
"patches": [],
"patch_tool": "patch",
"patch_args": [
"-p0"
],
"patch_cmds": [],
"name": "com_google_protobuf"
}
}
]
}
]
This includes the original attributes, which is where that URL you're looking for is. It also includes any additional information returned by the repository rule (ie for git_repository, the actual commit a given ref refers to).
I got that example from blog post introducing that flag, which also has some more background.
I'm trying to package my electron app, using electron-forge. In order to make the app available on macs, I need to codesign the app, which requires passing info such as appleId and app-specific-password in the package.json file.
How can I pass this information securely? (ie, not available to people who download the app)
If environmental variables are the way to go, I'm hoping to understand where I set the environmental variables (in a separate file? In the start command?) and how I access them in the package.json itself.
I'd appreciate any help to sort this out.
Details of what I've considered:
-The electron forge codesign documentation does not mention how to actually provide osx required details in a secure way. It does mention that it uses electron-notarize (among others) under the hood, and electron-notarize's documentation says: "Never hard code your password into your packaging scripts, use an environment variable at a minimum", but doesn't provide detail on how to do that.
-This stack overflow answer provides helpful info in terms of setting up a separate forge.config.js file, and then says you should "load your environment variables using process.env.YOUR_VARIABLE_NAME". It doesn't provide more detail--loading the environmental variables for a packaged app is what I'm trying to figure out here.
--This stack overflow answer mentions setting them manually, but doesn't mention how. It also mentions using the dotenv package--but I'd be surprised there's a separate package required for this task that is fundamental to any mac electron app.
I store them in an .env file in my project directory as follows:
APPLEID=your_id
APPLEIDPASS=your_password
In package.json I have a section:
"build": {
"productName": "PRODUCT",
"appId": "your app id",
"copyright": "Copyright",
"directories": {
"output": "build"
},
"afterSign": "scripts/notarize.js",
The afterSign points to a script scripts/notarize.js that will pull out the APPLEID and APPLEIDPASS using dotenv:
require('dotenv').config()
const { notarize } = require('electron-notarize')
exports.default = async function notarizing(context) {
const { electronPlatformName, appOutDir } = context
if (electronPlatformName !== 'darwin') {
return
}
const appName = context.packager.appInfo.productFilename;
return await notarize({
appBundleId: 'your app id',
appPath: `${appOutDir}/${appName}.app`,
appleId: process.env.APPLEID,
appleIdPassword: process.env.APPLEIDPASS
})
}
It's those 2 last lines with appleId and appleIdPassword that pull out the environment variables.
Never commit the .env file to, for example, github. To make sure: add .env to your .gitignore file. Also: the script/notarize.js app is not part of your app itself, this runs while you build your app.
I've been able to hear back from one of the maintainers of electron forge, who said the way to do it is:
Load the environmental variables in the build script itself. For example: $ VAR1=something VAR2=somethingelse npm run make.
Then, reference those variables as appropriate in the forge.config.js file that package.json refers to. Example reference syntax: process.env.VAR1
I'm currently struggeling with following issue.
Developing in Lua
Different file encoding per file extension (for instance: "*.lua" -> iso88591, "*.lu8" -> utf8)
Actually there is no way to solve this in the settings.json (only per language).
So I decided to develop an extension setting the charset per file name (custom setting charset.assignment).
settings.json
...
"files.associations": {
"*.lu8": "lua"
},
"[lua]": {
"files.encoding": "utf8"
},
"charset.assignment": {
"*.lua": "iso88591"
},
...
So now I "only" have to set the character set of the current file in my extension.ts, but I didn't find any opportunity to do this. At the moment I'm trying to execute the workbench command workbench.action.editor.changeEncoding, it shows up, but I still have to manually chose the character set.Anyone knows, if it's possible to refer some parameters to the command (like vscode.commands.executeCommand('workbench.action.editor.changeEncoding', 'iso88591');?
Similar question (but for getting the current charset):
VSCode: activeTextEditor encoding
Links:
Provide encoding-related APIs for editor extensions
add support for charset
ChangeEncodingAction
File extension specific settings
I'm reading through electron and electron-builder docs, but I still do not quite understand what is the purpose of the buildResources folder?
Here's what a configuration doc for electron-builder says:
buildResources = build String - The path to build resources.
Kind of self-explanatory... But how or when they are involved in the build process, especially having that:
...build resources is not packed into the app. If you need to use some
files, e.g. as tray icon, please include required files explicitly
Can we simply put those icon files in an arbitrary folder and then copy over into the app/ manually (since we need to include buildResources manually anyway)?
TL;DR:
As far as I can tell from a quick glance at the source code, the buildResources folder is used to hold additional scripts, plugins, etc. that can be used by the package building software. Electron-builder doesn't generate the packages itself, it uses tools like NSIS.
Explanation:
I've had the same question and unfortunately find an answer for this isn't very straight-forward. The docs entry is pretty useless. I found out that someone asked about it in the GitHub issues but never got an answer.
I decided to dig in the code a bit myself to find out what it does. In NsisTargets.ts, you can see that the buildResources folder can contain custom includes and plugins for NSIS.
// NsisTargets.ts
taskManager.add(async () => {
const userPluginDir = path.join(packager.info.buildResourcesDir, pluginArch)
const stat = await statOrNull(userPluginDir)
if (stat != null && stat.isDirectory()) {
scriptGenerator.addPluginDir(pluginArch, userPluginDir)
}
})
// [...]
taskManager.add(async () => {
const customInclude = await packager.getResource(this.options.include, "installer.nsh")
if (customInclude != null) {
scriptGenerator.addIncludeDir(packager.info.buildResourcesDir)
scriptGenerator.include(customInclude)
}
})
and in pkg.ts it's used to load additional scripts to the pkg builder:
// pkg.ts
if (options.scripts != null) {
args.push("--scripts", path.resolve(this.packager.info.buildResourcesDir, options.scripts))
}
It appears as though buildResources can contain assets/scripts specifically used for the build process. That also explains why the contents of buildResources aren't included in the resulting app.asar file.
So, I'm going to say straight away that the documentation for this option is just awful.
Files included in buildResources will appear in the asar file which you can find documentation about on electron's website.
The option files will include files such as pictures which are not accessible in the asar file.
I.E.
given I have a folder called assets in my build folder I want to include with my app.
"files": [
"./build/**/*"
],
"directories": {
"buildResources": "assets"
}
This will put all folders inside build into the asar file, which you can then unpack by including,
"asarUnpack": "**/assets/*"
This will put the folder assets into the build folder in the app directory.