Something I threw together over the weekend. I've been using filepicker on a website of mine. Realized that I could hack it to upload and share files in a simple tool.
Inspired by cloudApp, when I found myself wanting a command line version.
Seems like this could be done with more respect for user/data sovereignty if done with Node.js. Essentially, you'd cat the file into the script, it would spin up an HTTP server, do some port knocking or whatever NAT-traversal-fu is necessary, then spit out a link with either your raw IP, or a preconfigured dynDNS domain name.
This way we aren't carelessly littering our data all over the "cloud".
... send people a link to https://yourname.pagekite.me/file.blah and it streams from your disk. CTRL+C and it's offline with no copies stored anywhere in the cloud. Works with entire folders too (append +indexes to generate indexes), which is good for static HTML demos. If you want a harder-to-guess URL, append the +hide flag to the command above.
And yes, it's open source and you can run your own relay/reverse-proxy if you don't want to rely on me. Give it a try! :-)
Woah, I'm in the big leagues now! Blocking us actually makes perfect sense, PageKite can be used to avoid a lot of quite reasonable corp security policies.
Know any port knocking as a service companies? If there was a reliable way to get a udp connection between hosts that I didn't have to write myself, I'd be tempted to take this on.
I think the term you're looking for is UDP hole punching, port knocking is performing a special sequence of connections (i.e. try TCP on 8100 then UDP on 4000 then TCP on 2000) to open up an additional port (like SSH) to a certain IP.
I'd be curious if there exists such a company or even any good open source libraries that can tie into other servers.
From that, it looks like any random person can fill up your filepicker.io space providing they have your API key or know the email address you used to register the account with. Made sense when I read a bit more about what filepicker.io actually does (i.e. a client-side embeddable javascript file uploader) but it's something to be aware of (especially if you link your account up to an S3 backend!).
One of the founders, just wanted to reply and say, yes, you are entirely right. We put up that endpoint for a separate purpose, didn't expect people to find it (underestimating people is clearly a bad strategy) and will be locking it down to require a password to create/find a apikey.
In general, the apikey doesn't actually provide very much security as is; by it's public by it's very nature as you have to put it client side and expose it to all your users. We've got HMAC and secret keys in the pipeline for next week :D
Also, isn't it normal to check the referrer when using API keys? That's what Facebook does -- API keys only work from certain domains, which effectively restricts their access. The downside is that you need to maintain separate API keys for every domain (staging, sandbox, etc), but the advantage is that they don't rely on the honor system :P
I have no idea why I haven't installed xsel already. The help mentions a secondary clipboard. X has a secondary clipboard? Is there a way to paste that (like middle click for the primary)?
Following the old zero-one-infinity rule[1], X has an arbitrary number of clipboards; the most commonly used are PRIMARY (select+middle click), CLIPBOARD (usually C-c/C-v or edit→copy menus) and SECONDARY which, as far as I know, can only be pasted using applications that support it (e.g. xclip -o).
This is awesome, it actually makes filepicker.io useful for me. My main use-case for Dropbox has turned out to be for this kind of sharing... geturl is waaaaaay easier.
Elaborate, sure, but it does the job. update.sh runs git push and then does an SSH into my server and a git pull. (Because I'm too lazy to actually set up git on my own server)
You don't need to set up a git server on your own sever. Just create a git repo, add it as a remote revenue to your local repo, and use ssh+git to push changes directly.
But if you have your own server, why don't you just scp it directly there? That's the piece most people are missing.
SCP is really the solution here. But to be fair, I only discovered scp after a year or two of CLI work. I might have been tempted to hack something together like Taze's solution in my earlier days
Something I noticed (https://www.filepicker.io/pricing/):
Since filepicker.io charges by number of files and NOT by total size of files, a free account could potentially host a huge amount of data.
It couldn't handle files with spaces, plus the link it gives initiates a download for the file instead allowing you to view it in the browser. Considering most of the time I want to quickly upload a file in this manner the file is a screenshot, this is basically useless for me.
> To make it easier to get started, if you haven't
> put in your S3 credentials we will store them on
> our servers, but as your usage increases we will
> ask you to move to your own storage.
Except that Dropbox has now discontinued their public folders in exchange for there get link everywhere (which requires you to click add to dropbox or a download button rather than direct access).
Yes - all that means is that now you can move a file into anywhere in your Dropbox, right-click it, and click (in the Nautilus plugin) "Share Link" and get a publicly available link.
The only thing that the Public folder did differently was that it did the equivalent of "Share Link" for every file in it, and also had a public index of files in the folder.
Inspired by cloudApp, when I found myself wanting a command line version.