It would be great to have an example a node server to the browser.

[trueshot]

I would like to be able to use a node server as my back end and have the browserFS be able to read and write files to that node server. None of the back ends seem to do this. Either I am missing it or this is a feature request.

[jvilk]

I am unsure of what you want here. XmlHttpRequest exposes a file system over GET requests, but requires a file index up front to function. It's read-only.

There is no standard protocol for exposing a file system for writing over HTTP, and doing so has a number of security implications! You'll need some authorization mechanism in place, otherwise anyone who can access the server can muck with your files.

You are free to write your own BrowserFS backend, which should inherit from the BaseFileSystem class. I'd recommend writing it in TypeScript, since it gives you static type checking, but you should be able to use regular JavaScript too (set the prototype to a new instance of BaseFileSystem).

Best of luck!

[trueshot]

So, the context for this is Atom, where you have access to the local file system, versus Atom in Orbit where you would like to have access to something that looks like a file system on a server. For an editor, obviously read only is not good. The ability to edit using Atom in the browser is the prize and accessing a specific directory on a server using the node file system conventions would be powerful.

And some security model is implied in using a web-base IDE.

[jvilk]

For Atom in Orbit, does the filesystem server run on the same computer as Atom in Orbit? Or is the filesystem server hosted elsewhere?

Let me sketch out the security concern.

• Scenario: A Node server that lets you store data in files in the file system using HTTP PUT requests. BrowserFS would use these HTTP requests to manipulate the file system.
• Problem: Anyone with network access to the server can overwrite files using PUT /path/to/file.
  • If the server is on the internet, then anyone on the internet has control over your file system.
  • If the server is local to your computer (e.g., localhost), then any application running on your computer can overwrite files.

Do you see the issue?

You need some sort of login mechanism to only let valid requests manipulate the file system. Developing a secure generic login service / cloud storage mechanism like that is outside the scope of BrowserFS.

With that said, BrowserFS does support Dropbox, and could be extended to support other existing cloud storage solutions / APIs.

[trueshot]

I guess I assumed you knew what Atom In Orbit was all about since Facebook specifically mentioned your project in connection with it.

https://github.com/facebooknuclide/atom-in-orbit

So an editor in the cloud does not do anyone any good if it can't do the whole FS part and Atom already uses FS for local file stuff, so Atom in Orbit has no purpose unless you can get files over the web thru the browser.

Obviously security is important to any website that has private content for credentialed users. And the web server obviously only allows access to a controlled set of routes. Many times, this is a specific directory and its children. I don't see why a Node server supporting browserFS would have to allow an arbitrary and unlimited path.

And the problem with using Dropbox is that we need server side control over what is really happening to the files. I need a non-proprietary server side solution.

Obviously, I am not suggesting that you write this server, it's just that when I heard of your project, a node server that served directory content was the obvious use-case that came to my mind.

[jvilk]

I guess I assumed you knew what Atom In Orbit was all about since Facebook specifically mentioned your project in connection with it.

Nope! This is my first time hearing about it. Sounds really cool! Are you working on that?

I don't see why a Node server supporting browserFS would have to allow an arbitrary and unlimited path.

The issue isn't arbitrary paths, its that all of the files that you want to serve with it will be public access (read/write) without some authentication mechanism (e.g., username/password, access token, ...). Does Atom in Orbit already have some sort of authentication mechanism?

It seems like whatever authentication scheme you use will be tailored to Atom in Orbit, and wouldn't be useful to anyone else. Right? If not, I need a sketch of your envisioned architecture.

The good news is that you can develop custom file system backend modules that "plug in" to BrowserFS, which I briefly discussed in the comment that closed the issue.

[trueshot]

I imagine the nuclide team at Facebook would be working on that, but I have no connection with them so all I know is what I have read.

Atom is a Github backed editor that works in a local instance of Chromium. It is a high quality editor that is 100% javascript. It also has node built into it with unfettered access to your file system via FS. There are now thousands of packages you enable and snap in.

Atom in Orbit is the attempt to allow this editor to run in the browser and be zero install.

An editor is usually a private thing, so yes it would have to be part of a larger security scenario. And obviously, this stuff can be done with standard web protocols, but I can't imagine what they would need browserFS for if it were not to fetch and save files through a comfortable interface onto a node backend, but maybe I am missing something.