MakeDrive auth should be pluggable, configurable, optional

[bolinfest]

I was able to get the MakeDrive server up and running, but I expected to be able to load http://localhost:9090/demo/?makedrive=ws://localhost:9090 and browse some files. Instead, I get an error in the console about a 401 unauthorized. I don't see any way to enter credentials, and there's nothing about how auth works in the README.

I also find it odd that there's no configuration around which directory on my machine I should be able to browse/write to. I expected to define this in the .env file.

I understand that security is important, but having everything locked down makes the out of the box experience pretty frustrating. (I was hoping I could just curl http://localhost:9090/p/ and see something, but that also resulted in a 401.)

[humphd]

Thanks for filing this. I could explain the reasons for all of the things you're describing above, but the reality it all boils down to whether MakeDrive wants to be a general purpose tool or just something we're using as part of Webmaker. I'd like to be able to support people like yourself using it in their own projects, and the fastest way for us to get there is to have our auth system be pluggable/configurable. The way that Webmaker does its auth is almost certainly not the way other people will want to do it.

I'm going to do two things:

• morph this bug into one about making the MakeDrive auth configurable/pluggable
• file a bug on fixing the docs to be less confusing, based on your findings above.

Thanks for filing.

[humphd]

Filed #452

[bolinfest]

@humphd Thanks for striving to make this a general tool! FWIW, I was trying to leverage MakeDrive in Atom. (I know that you already did an analogous integration with Brackets.)

Rather than SSH into my Linux box and use emacs/vi, I'd like to be able to use MakeDrive to edit my code from that remote machine locally in Atom. I would even settle for doing it over an insecure connection as a first step, just so it would be easier to start making progress on the necessary integration points in Atom.

[humphd]

Your use case fits with our goals in general, so I'd like to try and make it possible. Give us some time to figure out the right solution here, but I'm pretty sure we can do it.

[humphd]

@bolinfest we've got a patch we hope to land this week that makes our auth configurable and swappable. While we finish and review, I'd be interested to figure out what the auth case would need to be for your Atom experiments. At the very least, MakeDrive needs to be able to get a username (i.e., some unique string) to separate one user's filesystem from another. Interested in your thoughts.

[humphd]

@alicoding has landed #451, so this is basically fixed; but I'll leave open to hear from @bolinfest to make sure we've covered what we need.

[bolinfest]

Hi David, thanks so much for following up on this! I'm on PTO through the
weekend, but I'll take a look on Monday (Tuesday at the latest) to give you
feedback.

Offhand, I feel like there were two use cases. 1 was "hey I'm checking out
makedrive and I just want to get things running end to end to cobble things
together and see if I want to invest in this more, so I want no roadblocks
to author stuff" and then 2 is "OK, I'm sold. I want to use this in real
stuff and also do things right such that it's secure and works with
whatever internal or external security procedures I must abide by."

So both good OOTB and pluggability are key.
On Nov 13, 2014 6:02 PM, "David Humphrey" notifications@github.com wrote:

@alicoding https://github.com/alicoding has landed #451
#451, so this is basically
fixed; but I'll leave open to hear from @bolinfest
https://github.com/bolinfest to make sure we've covered what we need.

—
Reply to this email directly or view it on GitHub
#451 (comment).

[humphd]

OK, thanks for this reply. We've covered both cases now: 1) we do a zeroconfig provider OOTB so you automatically get a 'root' user with auth automatically handled; 2) you can swap in any auth provider you want to match your own needs (our Webmaker Auth is a great example of this, but so is the Github OAuth provider). As such I'm going to close this ticket.

However, please do bug us with other problems you hit, ideas you have, or issues that come up as you hack MakeDrive into Atom. We'd really like to see you succeed.

[LegNeato]

Thanks @humphd! 🍻

[bolinfest]

@humphd Sorry it took so long, but I finally got a chance to try this out tonight. For sure, the setup process was considerably better than before! The Installation and Use section in the docs is really great until the end. That's where you bury the lede. I load http://localhost:9090 and it responds with the most boring web page in the world. I have no idea if I set this up correctly or not.

Then the docs go into all sorts of detail about authentication. WAIT! I HAVE NO IDEA IF THIS IS WORKING OR NOT YET!

Buried at the bottom of the docs is information about a demo. A demo! Do you know what's more interesting than a swappable authentication mechanism? A demo, that's what! Both http://localhost:9090 and the end of the Installation and Use section should tell me about the demo.

What's really nice is that I didn't have to edit anything in .env in order to get the demo to work. This makes the out-of-the-box experience considerably better. (Though the fact that I didn't have to edit ALLOWED_CORS_DOMAINS is a little suspicious because I'm running Makedrive on a remote machine, so the default of localhost cannot possibly be right. Is that part of the docs about setting up the demo outdated?)

The only problem is that it took me quite awhile to figure out how to run the demo. I think this is where my mental model of Makedrive is particularly broken, so that's likely a major part of the problem.

I expected (and still expect, given the original blog post) to be able to start a Makedrive server on a remote machine and point it to a local directory on that remote machine that I can browse via the demo. This is important to me because it is on the critical path of what I would like to do with Atom.

Instead, I get a new, virtual folder. Because of the mismatch in my mental model, again I thought Makedrive was broken because I didn't see any of my files. I tried to open a file. Instead of getting a detailed error message, the cursor turns into a circle with a slash through it when I hover over the Open button. Clearly I'm doing something illegal, but I have no idea what.

Eventually, I try creating a file instead. That works! Well, sort of. The demo page doesn't preventDefault() on cmd-s, so trying to save brings up the browser's save dialog. Instead, I have to mouse over to the type of save button I haven't had to click on in about ten years. Finally, I save my file (named package.json) and then load http://localhost:9090/p/package.json in a new tab and see my content! I edit my content and reload /p/package.json and see the update! It's exhilarating! Now I know that I have finally gotten this thing to work!

Only once I have reached this point do I start to take interest in the other parts of your documentation. I still haven't figured out if it's possible for Makedrive to start serving the files on my remote machine, though. As a basic step, I would like to serve the files in my ~/public_html folder on my Linux server via Makedrive so I can edit them locally using an editor on my Mac rather than ssh in and use Emacs. Is this a supported use case right now?

[bolinfest]

I dug into this a little more. I see that FSProvider has a constructor that takes some options that could have a root property where I could specify the root of my filesystem rather than using the default /tmp/filer-data.

However, when I look at filesystem.js in MakeDrive, there does not appear to be any way to read a value from my .env file that becomes the value of options.root. Is there another way that I'm supposed to do this or is it just not implemented yet?

[bolinfest]

I tried hardcoding options.root in filesystem.js:

options.root = '/data/users/mbolin/makedrive';

Unfortunately, this still fails to load my directory, seemingly because of how it is supposed to be used with keyPrefix and you aren't allowed to have an empty keyPrefix:

FSProvider.prototype.open = function(callback) {
  if(!this.keyPrefix) {
    return callback("Error: Missing keyPrefix");
  }

  var that = this;
  var dir = path.join(this.root, this.keyPrefix);

Again, my expectations of MakeDrive feel like they're really off here.