I am going to add some kind of security in my site . So i was thinking that is this possible to have temporary url to physical files .
Suppose i have a javascript file which is needed by my login page in order to run correctly . So can i do this something like dynamic suppose we have a url which is valid for current session of user when user logout that url gets expired .
The main purpose is that i don't want to disclose real path to my file
The purpose of a virtual path is to hide the real path from the browser. You can make a virtual path that is different from the physical path and the outside world will have no concept of where your actual file is.
You can map a virtual directory to any directory on your file system so it has a virtual path. Let's say you want to make the physical directory C:\temp\Images\ into a virtual directory called /Images/ and you are using IIS 7.
Open Internet Information Services (IIS) Manager.
Under sites, navigate to the site you wish to place the virtual directory in.
Right click on the site node, and click "Add Virtual Directory...".
For the alias, type Images.
For the Physical Path, type C:\temp\Images\.
Click OK.
Now you can access your image through the virtual directory /Images/img1.jpg. The browser has no idea that it is in the physical directory C:\temp\Images\.
There is an issue with what you are proposing. If you did host your JavaScript file on a "temporary URL for the current session", it means that the browser would not be able to cache the file and performance would not be optimal.
I cannot see any advantage to what you are proposing because regardless of what you do, the browser (and thus the user) will have access to your JavaScript code. The only difference is you will have a lot of complex code to generate temporary URLs that seem to serve no purpose.
Related
I am new to web dev and currently building a very basic page using Html/CSS and JS where users can upload the image and I can download it in my local system. But by default images are getting downloaded in the 'download' section of my desktop and I want to save them to any specific folder. How can I add this functionality?
You can't.
You do not have access to other peoples file managers as that would be a major security risk.
Uhh... You can't manipulate the download folder from frontend. It may be a security risk.
This cannot be done by Javascript (otherwise we could all produce websites which saved files all over a user's local PC).
As the end user in this case you can go into your browser and tell it which folder to save downloads in by default. (And remember to change it back if you want any other downloads to go elsewhere).
Here for example is what I find on Edge on Windows10 when going into Settings>Downloads:
I'm wondering if it's possible to for certain JS files to be added to the web extension directory later?
Like say I have an app where users can select certain settings from within the app and those files (js and html files, images or blobs) are somehow added into the extension from the web. Like some sort of ondemand updater without using any native apps but it seems that upgrades are done by the appstores automatically.
I'm reading the files using ajax and adding them to indexeddb but because it could be more than one file that's getting messy.
Say a user wants a certain feature on the extension and there's an html page, js files and images then this gets downloaded to a certain folder inside the installed extension.
function download() { //only saves to downloads directory
var imgurl = "https://www.google.com.hk/images/srpr/logo11w.png";
console.log('download');
browser.downloads.download({url:imgurl},function(downloadId){
console.log("download begin, the downId is:" + downloadId);
});
}
I also tried the chrome download function above but that only works for the downloads folder not the extension folder.
Is there any way to make a custom updater?! I know we can't save to disk but any leniency or workarounds for the extension folder?! Even something silly like making a shell call to some dos (and linux/mac) thing that saves the file to the extension folder. I can fetch the files, just not save them.
Ok so I'll put it as an answer. This is the solution I'm leaning on which works for my scenario and I've listed some alternatives below:
Having the other files as separate extensions and giving the user an install link instead where they can install that extension, then those child extensions talk to the mother extension and they know the address to the resources in their child extension folder, so the mother gets the just the file locations from the children to load those assets from that folder. The child extensions are like bundles of those html and js with a background script which sends the addresses of these items to the mother.
https://developer.chrome.com/extensions/messaging#external
The drawback is that I'll have to see how that affects the urls like if I inject the html page from the child extension folder into the main interface using ajax then I can't use relative url's to any images in that 'cos the urls are relative to the mother extension folder.. I'll have to rewrite the child extension urls with the absolute paths into the html page to load images and js from the child extension html code which has relative urls.
Pros:
Cleaner and more persistent than indexeddb.
Files can be loaded normally from disk.
Cons:
User has to install separate extensions.
URL structure might be a bit confusing, need to rewrite urls if loading html from child. However this is only for image src's and where the javascript is loaded from so it's not such a big deal.
Other Possible Solutions:
Indexeddb which I'm already doing seems to be the preferred way of doing this but I really do not want to store every html asset in indexeddb. The upside is that while extensions need to be installed, this method can be done silently fetching and adding files without user interaction and indexeddb seems to be somewhat persistent. Might still end up using this because it is silent but having to load each asset from a database sounds like a nightmare.
The File Handle Api might have worked if I was working on Firefox only https://wiki.mozilla.org/WebAPI/FileHandleAPI
I haven't tried the shell copy, maybe if I fetch with ajax and then save to disk using some dos function and then doing different save functions for different OS systems.
Filesystem Api only saves to downloads and doesn't work for extensions anyways, so that's useless.
UPDATE
In windows there isn't any sudo, but this worked without admin priveleges for a subfolder (not on the C:\ root though). It would work for a linux only app very nicely. If I just wanted to save a file to a windows machine this might work.
Shell copy method would be to grab the contents of file with ajax from the local or remote location, output to DOS as a stream to save to file on windows. And do this for every operating system with a shell exec command or detect the OS and do that command. This way I can even put the files in the exact folder location.
Like say I make this sort of command from the contents:
//To append you can use >> instead of >
//folder seems necessary, can't save to root without admin
echo the content I want to save > C:\folder\textfile.txt
I thought of calling it using shell exec that only works in nodejs, so digging through the other answers on
How to execute shell command in Javascript
//full code to save file using javascript on windows
var shell = WScript.CreateObject("WScript.Shell");
shell.Run("echo content to save > C:\folder\textfile.txt");
The shell command doesn't seem to work. i can't find what this is for. There doesn't seem to be a shell command in regular javascript for windows. It seems to require IE ActiveX. Doesn't work with Firefox or Chrome.
Extensions can't modify their sources because the browser verifies them and resets/disables the extension if they change. Also, in Firefox the extensions aren't even unpacked.
The solution is actually quite trivial: save the code in any storage (localStorage, chrome.storage.local, IndexedDB) as a string and then add it in your extension page as a standard DOM script element. You'll have to relax the standard CSP a bit for that.
I have a web application that triggers actions at the server side which result in the generation of data files.
The so generated data files are stored within a folder at drive different from the one where the Web application is.
What I tried so far is to create a shortcut (Windows Server) next to the Index.html, where the shortcut points to the folder at the second drive.
This solution does not appear to work:
If I copy the data file to the same folder where the Index.html file is and enter navigate to the URL httm://127.0.0.1:324324/Data_File.xlsx I get the file downloaded.
If I enter httm://127.0.0.1:324324/MyShortcut/Data_File.xlsx (where MyShortcut points to a folder in drive D) the attempt fails.
How can I achieve this?
The need to access files in the different drive is essential.
You need to configure your server to serve that folder under different location. The only reason you are able to see your app and access that folder is cause server is set up to serve it ATM, not because you are making the right calls from the front or cause the front is asking nicely.
Don't know what Windows server version you are using and IIS version that goes on it, or are you even using IIS (you most probably do) but depending on what you use you need to do something in a lines of this:
IIS7 config
What you probably wanna do is create virtual folder in IIS. Try looking into it, then if you fail ask a question with proper tags according where are you stuck.
I don't see how this is connected to front-end at all so front end tags wont get you far.
EDIT:
Oh, in that case get a second file server running for that folder? This should be the fastest way, use what you can from this list: list
I'm testing some of the new JS filesystem abilities, i.e. creating an empty text file in the local filesystem. I'm running the HTML & JS files from a local path (file:///). For this purpose I launched Google Chrome with the --allow-file-access-from-files flag from the CLI. The filesystem request is PERSISTENT (and works).
I have read up on different posts about the filesystem, copied and modified some of the code in the tutorials; When I launch the HTML file, my custom success/ failure messages are outputted in the console;
This is the result:
Opened file system:/ // this is the root path of the JS Filesystem.
/wtf.txt // this is the name and path of the text file I created+ it's a success
However, when I look at my directory's (both system and application root), there's no .txt file with the name I assigned to it. How can I know where Javascript really wrote this file? In what "root" (since the 'root' cannot be assigned)? What does it mean that the FileSystem is a 'sandbox'? That I cannot access the (virtual?) contents of it on my local drive, but only with JS? If this is the case, is there a way to prompt the user to save the file?
Thanks in advance for your answers
It seems you're expecting the File System API to work locally similar to an OS file system. The client doesn't work like that. In fact, and API is designed to be your interface, as a programmer, to the files and directories -- the client itself (e.g., Chrome, etc.) will handle the rest on the local level. The API is not designed by which you can create a file via the browser and easily access it via the operating system.
How can I know where Javascript really wrote this file? In what "root" (since the 'root' cannot be assigned)?
Technically speaking, each client can store locally as it chooses. So while you can go to the local file system to look for the file, something is wrong with your approach if you're attempting to do so; the File System API is not meant for that. To your question, you can assume that if there's content the client's storage area (e.g., for Chrome it's something like "C:\Users\USERNAME\AppData\Local\Google\Chrome\User Data\Default\File System\") then you can assume that the JavaScript wrote it. But again, it's not set up for user friendly browsing on the local system.
What does it mean that the FileSystem is a 'sandbox'?
Sandbox simply means an area created and set aside for a specific purpose, outside of which the client cannot see/access. See this from Mozilla: https://developer.mozilla.org/en-US/docs/WebGuide/API/File_System/Introduction#virtual
That I cannot access the (virtual?) contents of it on my local drive, but only with JS?
That is correct, and by design.
If this is the case, is there a way to prompt the user to save the file?
If I understand your question right, you're asking if there is a way to provide a specific file to the user and have it prompt them to save it locally. Well, of course if you provide a link to the file (or push it, a different discussion) then the client will prompt the user to save/store it if their platform allows them to do so. But you have no control over where they save it locally nor can you later get it it. If I've misunderstood your question, comment below and I'll follow up.
I'm trying to link to the directory above the web root, but it doesn't work in JavaScript. It doesn't matter how many ../ I use, it doesn't go more than twice, which is required to reach the web root. (Using PHP this works fine, though) I think it should be possible right? Could it be a permission problem? Thanks.
JavaScript is clientside -- it runs on the browser, not the server. A correctly set up server will not let clients access stuff outside the designated area, independent of whether it's from entering an URL into the addressbar, a link contained in an HTML page, or a URL created by JavaScript. It's all the same for the server anyway -- it's just an URL.
If you want to reach website root name, It's here:
var root = location.protocol + '//' + location.host;
//For a url, let say 'http://google.com/ig', it will return 'http://google.com'
But, Christian Stieber's answer is right If you want to reach any of server's file.
Javascript works on the client side. Client side doesn't know anything about the fylesystem of server so can't know or access anything there - client's root is domain name and adding one more '..' means trying to dive above domain name, not above one level in filesystem.
You can't link to a folder above the web root, because it simply doesn't exist.
You link to a web resource, not a physical folder. This resource usually corresponds to a file or folder stored physically on the server, but it doesn't have to. When it does correspond to a file or folder in the file system, it's only folders under the folder corresponding to the web root that is a part of the resources in that web. Anything above the folder is simply not part of the web. Eventhough it exists in the file system, it doesn't exist as a web resource.