Certainly, there is no need to put <span> tags inside <div> tags, that is invalid HTML5 or at least according to W3C validator.No offense meant to the author. Peace!
Thanks for your feedbacks!
In fact, I developed this tool just to get some help in my everyday work, because I'm used to connect to several SSH at the same time of my customers (My Terminal => Bridge SSH => Target SSH), and it can become a little bit confused with SCP command..! This kind of tool helped me a lot, and I choose to share it with other DevOps/SysAdmin.
@beeskneecaps: I never thought about the link to destroy immediately the file, I'll put it tomorrow, thanks :)
I'm the author, @dizzda on twitter, you'll get additional informations about me.
About the security, i'll be honest, it was just to see if the concept can be interesting for other people, the only security (yet) is that the file will be auto-deleted in 4 hours.
Files are hosted on a private dedicated server. So yeah, you can always take care to encrypt yourself your file before send it there.
If many people are interested to use this tool in a more professionnal-way, I can take some time to think about it...
Anyway, it's just a real pleasure to hear your feedbacks guys! Please do not hesitate!
There were 2 issues, one copying the script onto every machine and the second one related to login credentials. Some scripts needed an authentication file and others need it on prompt. Unfortunately keys(both S3 and dropbox) are not handy all the times.
Couldn't find any feedback form on the site, so I guess I'll post it here. Seems there's a small bug in the way the time, dispayed in the console, is calculated.
FilerCtrl uses:
var c = new Date;
a.date = c.toDateString() + " " + ("0" + c.getUTCHours()).slice(-2) + ":" + ("0" + c.getUTCMinutes()).slice(-2) + ":" + ("0" + c.getUTCSeconds()).slice(-2);
Thanks for the feedback, indeed I didn't want to use momentjs to overload the speed of the site, but I didn't notice for that mistake, thanks I appreciate :-)
Typing in file name within a page just to generate URL seems clunky to me. I believe, you can provide URL generation from a REST API that can be called from command line.
Hey, I'm not sure that the SSL certificate will change something in the trust of the website, because the file will be hold by the website anyway. So according to me, I think you have to encrypt your file before sending it to the server, that you'll be sure to be the only one who can read your file (and other people who you give your passphrase).
I've updated the website with gpg encryption w/ passphrase FYI.
That's not really relevant to what's going on here. This isn't some script you're blindly downloading/executing from an untrusted source, and it's certainly not a phishing attempt with a seemingly innocuous URL that is actually malicious once you copy it.
You can just `man curl` and find out exactly what's going on here. (http://unixhelp.ed.ac.uk/CGI/man-cgi?curl, scroll down to the bit on "--form", and check out the example) I think curl.io, the service, merely accepts this form data and stores the file on their servers, allowing you access. But you should easily be able to point at your own HTTP server and do all the same stuff. I don't see any "magic" here, other than a little web app that's responsible for taking in the data and writing whatever that data is to a given filename.
It is absolutely relevant. Did you check the link I posted? I understand completely what's going on here, and the important part is that the website is inviting you to copy a command from the website and paste it into your terminal.
Now, even if you're OK with giving curl.io your files and trust it enough to not insert malicious commands into the command you're pasting (see link from my GP comment), since the connection is on clear text, anyone between your machine and curl.io can in theory modify the command text you're invited to copy-paste, and inject malicious commands of their choosing.
Great idea but where I'd find value in something like this is for securely transferring files to people who, presumably, are somewhat clued. If I needed to do that, doing it without SSL seems counter productive (as has been pointed out). Additionally, while the four hour deletion is nifty, were I building this (could be a fun toy to hack together), I'd like a settable timer or download count. The comment about auto generating to URI path is spot on too. Sure, it would be nice to be able to choose but in many cases, a randomized path is ideal.
Again, cool toy and a fun idea but...
Too bad the code isn't available so I could hack it up a bit. I've saved this, in case bored and want to give it a try on my own some time.
You might be interested in this project I worked on https://github.com/abemassry/wsend-gpg it's end to end encryption, there's no settable timeout but there is a delete command so something like what you're saying might be possible.
I've already posted below but wanted to share this with you incase you're interested.
In my case, I going through several SSH (My Terminal => Bridge SSH => Target SSH) to get for example a backup. It's just easier for me to get the file back with curl.io instead of using something like SCP in this kind of situation.
The cat version much more clearly represents the flow of data. We read left to right, it makes no sense to me to have data flow written right to left (and only for input files, while output files read left to right).
When building commands up from basics, it makes much more sense to start with cat. I will typically cat the file to see it's contents, then modify the command with a pipe to another program, and make keep adding processing steps to the end of the pipeline. Your < inputfile.txt notation completely breaks this model.
Just because you read something on a webpage that one time doesn't mean it is the one true way.
No, it makes much more sense to start with the command that is to process the file. Most commands take a command line argument to specify which file to process. This mirrors the redirection syntax perfectly:
You say:
grep haystack needle.txt
or:
grep haystack < needle.txt
whereas this is more convoluted:
cat needle.txt | grep haystack
As a bonus the syntax looks the same for output redirection:
sort < infile.txt > outfile.txt
whereas this is not as readable:
cat infile.txt | sort > outfile.txt
What "makes sense" to you doesn't always to other people. In this case it's trivial, but it's a nightmare to debug larger scripts when there are lots of unnecessary redirections and if statements.
Shell scripts may be one-offs, but they tend to linger. It's not unwise to spend a few extra moments to make them readable and follow best practice. It is code after all.
Well, as I can see the most of you are worried about the security, that I understand.
So I've just added little help with a GPG encryption right from your terminal before sending the file.
I think this is the most important things I can make right now, while I do not plan to install SSL certificate given that I don't make money with this site, and the server cost is enough.
But if some of you, guys, are interested in more professional features, let me know, we can discuss about it.
67 comments
[ 4.9 ms ] story [ 119 ms ] threadThe other magic is, on Mac you can see the upload status in the browser window if you keep curl.io open.
I'd want an interface to destroy the file immediately then fallback to the 4 hour auto-delete.
Also some serious details about the author and security before I'd actually consider sending anything mission critical.
But http://validator.w3.org doesn't give me errors about spans or divs. It just gives errors with attributes.
@beeskneecaps: I never thought about the link to destroy immediately the file, I'll put it tomorrow, thanks :)
I'm the author, @dizzda on twitter, you'll get additional informations about me.
About the security, i'll be honest, it was just to see if the concept can be interesting for other people, the only security (yet) is that the file will be auto-deleted in 4 hours. Files are hosted on a private dedicated server. So yeah, you can always take care to encrypt yourself your file before send it there.
If many people are interested to use this tool in a more professionnal-way, I can take some time to think about it... Anyway, it's just a real pleasure to hear your feedbacks guys! Please do not hesitate!
Cheers, dizda.
iTerm: http://grack.com/blog/2011/10/26/automatic-file-transfer-in-...
S3 is as easy as:
s3cmd put FILE [FILE...] s3://BUCKET[/PREFIX]
Dropbox is automatic, just move a file to a local directory. They have CLI tools, though. If you want the public url, it's just:
$ ~/bin/dropbox.py puburl ~/Dropbox/Public/file.zip
If you don't want dropbox running all of the time, just use the 'start' and 'stop' arguments to dropbox.py.
References: http://s3tools.org/usage
http://www.dropboxwiki.com/tips-and-tricks/using-the-officia...
#!/bin/bash
X=$(cd $(dirname "$1") && pwd -P)/$(basename "$1")
curl -F "file=$X" http://curl.io/$2
You should also provide a copy to clipboard button.
does anyone else think this is slightly suspect and/or bogus?
FilerCtrl uses:
Which does not respect the current timezone.I suppose it could be fixed by replacing
with Although you'd probably be better of using a library like http://momentjs.com/.Copying commands from untrusted websites (or insecure connections) and pasting them into your terminal is not a good idea:
http://thejh.net/misc/website-terminal-copy-paste
If you don't trust curl.io, fine. But without TLS the list of people you need to trust is not only curl.io, but everyone else in the tubes too.
I've updated the website with gpg encryption w/ passphrase FYI.
You can just `man curl` and find out exactly what's going on here. (http://unixhelp.ed.ac.uk/CGI/man-cgi?curl, scroll down to the bit on "--form", and check out the example) I think curl.io, the service, merely accepts this form data and stores the file on their servers, allowing you access. But you should easily be able to point at your own HTTP server and do all the same stuff. I don't see any "magic" here, other than a little web app that's responsible for taking in the data and writing whatever that data is to a given filename.
Now, even if you're OK with giving curl.io your files and trust it enough to not insert malicious commands into the command you're pasting (see link from my GP comment), since the connection is on clear text, anyone between your machine and curl.io can in theory modify the command text you're invited to copy-paste, and inject malicious commands of their choosing.
Seems many new ideas around file sharing recently. To name a few:
- https://popbox.io
- https://nfil.es
- https://wsend.net
https://github.com/uams/geturl
Not your fault of course. We've all lost kittens to NAT.
Again, cool toy and a fun idea but...
Too bad the code isn't available so I could hack it up a bit. I've saved this, in case bored and want to give it a try on my own some time.
I've already posted below but wanted to share this with you incase you're interested.
Server:
Client: We tend to forget how the network is built, and how easy it is to use it with the right tools.The first command can be given more easily as:
(which also mirrors the logic of the second, modulo nc's idiosyncratic argument syntax)When building commands up from basics, it makes much more sense to start with cat. I will typically cat the file to see it's contents, then modify the command with a pipe to another program, and make keep adding processing steps to the end of the pipeline. Your < inputfile.txt notation completely breaks this model.
Just because you read something on a webpage that one time doesn't mean it is the one true way.
You say:
or: whereas this is more convoluted: As a bonus the syntax looks the same for output redirection: whereas this is not as readable: What "makes sense" to you doesn't always to other people. In this case it's trivial, but it's a nightmare to debug larger scripts when there are lots of unnecessary redirections and if statements.Shell scripts may be one-offs, but they tend to linger. It's not unwise to spend a few extra moments to make them readable and follow best practice. It is code after all.
(Also; a bit silly with the personal attacks.)
Also, HTTP is more accessible than raw TCP (you can use it from the browser)
Thanks for all these feedbacks!
I have considered most of them.
Well, as I can see the most of you are worried about the security, that I understand.
So I've just added little help with a GPG encryption right from your terminal before sending the file.
I think this is the most important things I can make right now, while I do not plan to install SSL certificate given that I don't make money with this site, and the server cost is enough.
But if some of you, guys, are interested in more professional features, let me know, we can discuss about it.
Cheers!
dizda