Is there a way to programmatically determine the path to the Chrome Extensions folder? I want to make a call like the following:
xhr.open( 'GET', chrome.extension.getURL( '/' + msg.file ), true );
to consume the contents of a file I create with a native messaging host (so as to get past the 1MB pipe limitation for certain responses). I can see what my 'profiles' path is in chrome://version, but I cannot find anywhere where this might be exposed (was hoping, at the least, it could be exposed to extensions). Furthermore, there's a version subfolder that I do not know how it is constructed, e.g. I have the following subfolders for the Chrome Media Router extension:
5216.530.0.13_0
5216.530.0.14_0
5216.530.0.14_1
everything up to _ is the version from the manifest.json, but I don't know how/when the part after the _ comes into play (my guess is it is used to distinguish updates to the webstore when the version number is not changed).
so I really would most prefer an API function that would get me the full path for my extension from the extension.
Related
I’m using Electron Builder to compile my Electron app to an .AppImage file, and I’m using the fs module to write to an .json file, but it’s not working in the appimage format (it’s working fine when I have the normal version not made with Electron Builder). I can still read from the file.
The code (preload):
setSettings: (value) => {fs.writeFileSync(path.join(__dirname, "settings.json"), JSON.stringify(value), "utf8")}
The code (on the website):
api.setSettings(settings);
The project: https://github.com/Nils75owo/crazyshit
That's not a problem with AppImage or Electron Builder but with the way you're packaging your app. Since you didn't post your package.json*, I can only guess what's wrong, but probably you haven't changed Electron Builder's default behaviour regarding packing your application.
By default, Electron Builder compiles your application, including all resources, into a single archive file in the ASAR format (think of it like the TAR format). Electron includes a patched version of the fs module to be able to read from the ASAR file, but writing to it is obviously not supported.
You have two options to mitigate this problem: Either you store your settings somewhere in the user's directory (which is the way I'd go, see below) or you refrain from packing your application to an ASAR file, but that will leave all your JavaScript code outside the executable in a simple folder. (Note that ASAR is not capable of keeping your code confidential, because there are applications which can extract such archives, but it makes it at least a little harder for attackers or curious eyes to get a copy of your code.)
To disable packing to ASAR, simply tell Electron Builder that you don't want it to compile an archive. Thus, in your package.json, include the following:
{
// ... other options
"build": {
// ... other build options
"asar": false
}
}
However, as I mentioned above, it's probably wiser to store settings in a common place where advanced users can actually find (and probably edit, mostly for troubleshooting) them. On Linux, one such folder would be ~/.config, where you could create a subdirectory for your application.
To get the specific application data path on a cross-platform basis, you can query Electron's app module from within the main process. You can do so like this:
const { app } = require ("electron"),
path = require ("path");
var configPath;
try {
configPath = path.join (app.getPath ("appData"), "your-app-name");
} catch (error) {
console.error (error);
app.quit ();
}
If you however have correctly set your application's name (by using app.setName ("...");), you can instead simply use app.getPath ("userData"); and omit the path joining. Take a look at the documentation!
For my Electron Applications, I typically choose to store settings in a common hidden directory (one example for a name could be the brand under which you plan to market the application) in the user's home directory and I then have separate directories for each application. But how you organise this is up to you completely.
* For the future, please refrain from directing us to a GitHub repository and instead include all information (and code is information too) needed to replicate/understand your problem in your question. That'd save us a lot of time and could potentially get you answers faster. Thanks!
I am building a React application which needs to display images dynamically which are stored, by the thousands, on a server-side file system. All of my attempts to successfully implement this have failed, including many which were taken from responses to similar questions.
Some details:
I used create-react-app to initialize my application. I am running in development mode (have not run npm-build). I'm using Express.js (Node.js) as a web-server, which I interact with through a proxy (only '/api' http requests use the proxy). My js code which attempts to 'require' the images is in the 'src' folder. The images are located in an 'images' folder in the default 'public' folder.
I thought I had found the solution when reading this page from create-react-app, as it states to use the public folder when 'You have thousands of images and need to dynamically reference their paths'. The page further instructs to use '%PUBLIC_URL%' or 'process.env.PUBLIC_URL' to access the 'public' folder. When using either of these I receive an 'Error: Cannot find module' message. Upon checking I notice that 'process.env.PUBLIC_URL' contains an empty string, and quickly notice that PUBLIC_URL is ignored in development mode.
I find this to be tremendously confusing, given that the 'Using the Public Folder' page is apparently describing the development phase of production, and yet it advises the use of something which is meaningless during development. Adding to my confusion, it appears as if the contents of that page resolved the issue for nearly all of those who have encountered a similar requirement in the past (example: 1, example: 2; both fail for me). Likewise, all attempts to to construct relative paths to the 'public' folder from the 'src' folder have yielded error messages. Failed code example:
let img = process.env.PUBLIC_URL + '/images/Team.jpg';
<img src={require(`${img}`)} alt="X" />
Error: Cannot find module '/images/Team.jpg'
I never imagined showing images in React would be so difficult. Any help is truly very much appreciated.
I think you are correct, you just don't need the require, return <img src={process.env.PUBLIC_URL + '/img/logo.png'} />; as you can see their docs
If you open in your browser http://localhost:PORT/images/Team.jpg that should open.
That's the reason process.env.PUBLIC_URL is empty in development, because they resolve everything inside this folder directly.
How do I make WKWebview use local .js, .css and/or local image files, in place of remote files, in order to make the web page load faster.
Also, I noticed NSURLProtocol methods (when implemented through register class) do not get called when WKNavigationDelegate methods are implemented, any idea on why?
In iOS 9 API there is a new method for loading local resource
/*! #abstract Navigates to the requested file URL on the filesystem.
#param URL The file URL to which to navigate.
#param readAccessURL The URL to allow read access to.
#discussion If readAccessURL references a single file, only that file may be loaded by WebKit.
If readAccessURL references a directory, files inside that file may be loaded by WebKit.
#result A new navigation for the given file URL.
*/
#available(iOS 9.0, *)
func loadFileURL(URL: NSURL, allowingReadAccessToURL readAccessURL: NSURL) -> WKNavigation?
After going through a lot of documentation, I realized/learnt that I'll not be able to track URLs if I use WKWebviews. I have to resort to UIWebView for the moment.
I know that I can't get a local file from within the extension directory. It is possible to get a file that is inside the extension directory itself?
You can use chrome.runtime.getURL to get a fully-qualified URL to a resource.
// Outputs path to the file regardless if it exits
> chrome.runtime.getURL('assets/extension-icon.png');
"chrome-extension://kfcphocilcidmjolfgicbchdfjjlfkmh/assets/extension-icon.png"
The chrome-extension protocol plus the extension id, will be the address for the extension's root directory.
If you need something more powerful, you might also use HTML5's FileSystem API which can create, read, write and list files from a sandbox in the current user's local file system.
On Chrome 17 or later, for this to work you must include the web_accessible_resources section to allow an image packed within the extension to be injected into a web page. http://developer.chrome.com/extensions/manifest.html#web_accessible_resources
{...
"web_accessible_resources": [
"images/my-awesome-image1.png",
"images/my-amazing-icon1.png"
],...}
(courtesy of jhaury)
We have a legacy (classic asp) CRM that I maintain in my organization. Users may upload files through the web front, they are stored on a network share and the filename, uploader, etc is saved to a database. Everything is well and good with the exception of .config files.
For some reason certain people can download these just fine, but other people recieve this error:
The type of page you have requested is not served because it has been explicitly forbidden. The extension '.config' may be incorrect.
it would seem that on some users computers the link for the file is "file://networkshare/filename" (which works) and on other machines it is "http://networkshare/filename". (which doesn't work)
I have the mime type for .config set to text/plain in iss6. All users are running IE8.
The code on the page creates a href links based on records returned from the database.
Why then is there there the difference in the way the link is rendered differently in the same browser on different pc's? How do I allow .config files allowing people to view the sites web.config?
The code that builds the link is:
function getlink(file_nm,path)
{
thisPage.navigate.CheckDocumentAttachedToRequest(file_nm, path)
var sDocLink = path.replace(/\//g,"\\") + "\\" + file_nm;
return "<A class=\"parislink2\" TARGET=\"_BLANK\" HREF=\"\\\\" + thisPage.get_sServerName() + "\\" + sDocLink + "\">" + file_nm + "</A>";
}
Weird.
I know that IIS 6 will return error 404.3 if a client request refers to a file name extension that is not defined in the MIME types.
However you do have it defined. You can try as a test using the wildcard () in your mime types. ( for the file extension and text/plain for the mime type.) The wildcard can be a security risk but if you are serving up configs..perhaps this application and server are internal to your network and it would be ok to use the wildcard.
I would also check your ISAPI extensions (not filters, but extensions) and make sure .config
is still in there. It should be by default.
Defining a mime type at the global level in IIS should filter down through and override any mime types set at the folder level.
An IIS reset is needed everytime you change mime types.
Perhaps it is a browser issue?
(an issue on the client side for the links that do not work..an issue like "browser control".)
It is almost as if some of the browsers are interpreting your function correctly when the link is built..and others are substituting "http" instead of "file" as the protocol when they render the HTML from the function call. Perhaps you could hardcode your function to us "file:" as a string that is placed at the begining of your link code. (trying to overide any "http" string that gets place in there by the HTML sent back by the server or rendered by IE8.)
The wildcard was filtered out for security purposes in the above post. (wildcard = "an asterisk")