brettcvz

Our concern is that if we return the direct S3 url, people less experienced will assume that the S3 url should work by default, when it will 403. So we return Filepicker.io urls which alias to your S3 bucket

Alternatively, use Filepicker.io.

filepicker.store(myFile, {location: "S3"}, function(FPFile){console.log("File stored in S3 at "+FPFile.key+" and available at "+FPFile.url);});

Got it! Good call, thanks

While I agree it can be a huge time suck, the way to deal with many of these things is to find the right people to outsource to (particularly for HR, corporate contracts, etc) rather than ignore entirely

In general, it's referring to the fact that you should be very careful with what you write down.

For example, if you send an email to a potential employee that the 10,000 shares you are offering them are worth $10,000, you've effectively valued your stock at $1/share. Now if you try to go and give options at $0.02/share and claim that is "fair market value", if the IRS ever saw the original email you would be in a bad situation.

Re. the grammar, happy to fix it up as necessary, it was done in a very conversational style as I didn't think it would be this popular, and likely has ways that it can be improved for clarity. Let me know what/where can be improved and I'll fix it up

Makes sense, will add an note on the paypal comment in github

Great! Happy to take a look at a pull request if you have one

Love the enthusiasm! To us, anything that helps makes products work more seamlessly together online is a win for the web and the world we want to see.

It also seems like Dropbox is encouraging a different use case, in that the links they provide by default are Dropbox share links that route back to Dropbox, and even the direct ones expire after 4 hours. With Filepicker.io, we want to be a more complete filesystem solution, offering things like store to S3, read/write on the URLs, conversion, etc.

To the cloud!

Yup, it's great to see that Dropbox shares our vision of helping connect online storage to online applications, so the spirit is the right one.

Our goal is for users to be able to connect directly to their online content, and we're working with Dropbox, Box, Google Drive, Skydrive, Facebook and others to make this happen.

There's always a balance between giving an overview for people who have never done this sort of thing before and writing to the aficionados with the battle scars of having done this a few times. Happy to share more detailed notes here, but as it was the original post was quite long already.

I would very much agree with you - the difficulty in writing APIs well come from the fact that 1) it is challenging to predict how people will use it, so you have to code defensively, make sure it's accessible to beginners and sufficiently powerful for experts. 2) once you've published it, even small tweaks become highly painful, increasingly so as you see success.

Love the parallels with U.N. Peacekeeping

Yup, didn't want to get into the weeds with the specifics, but we use the same procedure as AWS, where we use the shared secret to recreate the signature provided and then match the two (as well as verifying the method performed is allowed in the policy, and the expiry time is correct). Happy to go into more details if you'd like, also available at https://developers.filepicker.io/docs/security/

In reference to the js library as client-side, the key thing we were looking to solve was how to implement a token-based scheme where even if someone had access to the running javascript via xss or just malicious console behavior, the amount of damage they could do would be limited. Balancing that with the simplicity requirements to not use handshakes and allow for embedding urls within <img> tags resulted in the scheme we implemented

In general that's true, but specifically referring to public-key encryption only the holder of the private key will be able to create an encrypted message, so it serves as authentication

I like the breakdown between the three. The first two make sense from an API standpoint, hence why we have policies that can specify the range of what a bad actor has access to. We do auditing on our side to keep tabs on anything that seems out of place

Being able to create arbitrary files without asking the user gets into some nasty security issues, so we went with "export" instead. Once the user selects where they want to save the file to, you can then perform .read's and .write's on it

Oops! Sorry, bytes

Took a bit longer to handle the edge cases, but we now have the max file size stopgap implemented. On your developer portal you can set the maximum size that you'll allow to be uploaded. We're still moving forward with the more fully-featured security functionality, but wanted to make this available ASAP

We take this stuff seriously. Great, shoot me an email at brett at filepicker.io and we can walk through how to get you set up on the new security scheme

Also, given the feedback, we're implementing a way to set the max file size on your developer portal. Fix should go out in the next 10-15 minutes

On it! We have a new security release coming out next week that allows the use of server-side secrets to lock down both uploads and reads. We've already contacted the author and are happy to work with anyone who is concerned and get them early access

We're using the ability to talk over CMIS added in Sharepoint 2010

That's actually a clever idea, and opens up the door to connecting to servers directly over ssh

Given that it uses Filepicker.io, probably makes sense for us to take a look. The idea of turning files into URLs is one that we really like

We're working on it :D

To me, this is a big win for Dropbox but a big detriment to the ecosystem and other storage players. It's essentially like saying "Only works in IE6" - worked well to buy IE lock-in, but was a Bad Thing for the web. We, of course, want to help rectify this!

Yup, we can handle up to 50Gb (so far)

I agree - I really don't like the language Facebook uses for this. We need the ability to save photos back into your facebook, which facebook considers to be a "Post". We explicitly turn off notifying your friends, so we don't spam the world whenever you save a photo, but facebook still considers this a post and requires the corresponding permissions

We actually got a great looking design all ready to go, we just have to find the time to get around and actually code it up! Figured we'd add the functionality to the core product first before sprucing up our site/marketing side of things

Awesome! Shoot me an email at brett@filepicker.io and we'll send you a T-shirt

It's what liyan new best, so figured it would be a reasonable place to start and would be a good template for other PHP frameworks

We were looking at flask, but weren't sure the best way to make it a "library" - most of the basic functionality can be done via the requests library, for example.

With Rails, Django, etc. we were able to build into the ORMs and templating engine in a way that made for some cool magic.

Happy to help out - we'll send you a T-shirt too.

Edit: Looks like someone already started on one: https://gist.github.com/3203059