We're talking about 60 lines of python for the "server" and 90 lines of python for the "client".
That's a weekend hack, not a Dropbox clone.
It happened so many times in the past, that I'm patenting a method of getting on first page of HN:
1. Write something
2. Call it a dropbox clone
3. Congratulations, apparently no-one bothers to check if that "something" does anything even remotely similar to dropbox:
- does it have a GUI client with a highly polished interface?
- does it have an installer?
- does it have conflict resolution to reconcile changes made on different computers?
- does it try to not corrupt files if download/upload fails in the middle?
- is it self-contained or do you first have to install, say, python interpeter?
Here are somethings that I would consider adding:
* a README (update: done! :) )
* consider making this work with virtualenv by default. This way you can install
Flask as a library without making me install it for the system. Adding a short
bash wrapper script really helps here.
* support for folders
* sha1 hashes to ensure your files are consistent
* de-duplication of chunks would be a good thing to add too
* The way you are sending data now looks like you are using GETs for everything.
If you are really going to make this work, you should use GETs for downloading and PUTs or POSTs for uploading.
I know about no support for folders, I didn't have time to fix that yet, but I will!
Virtual enviornment is interesting, I will look into that.
* It does check for alterations actually then uploads the altered file, look at the main loop in the client.
The way I am sending files now is awful! I plan on fixing all thos, thank you for the response. :)
But, you it probably shouldn't have been submitted to the wolves in this state :).
Oops. What if my file is called " && rm -rf ~"?
I'll outline a few obvious issues I see:
- No explicit protection against directory traversal attacks (../../etc/passwd type stuff) on upload and download.
- Shell command injection on the file name on upload.
- Naive authentication.
- Unsalted, fast hash sent in the URL.
- Password stored in clear text server side.
- No transport security (HTTPS).
This is cool as a interesting project to work on, but it should be made clear not to use this for anything just yet.
I don't understand the point of hashing the password in the client anyway... The hash is as good as the password to an attacker.
It would be possible to use a challenge response authentication scheme (http://en.wikipedia.org/wiki/Challenge%E2%80%93response_auth...) but just doing things over HTTPS is generally fine.
Here is an example decorator: https://github.com/kamalgill/flask-appengine-template/blob/m...
In use: https://github.com/kamalgill/flask-appengine-template/blob/m...
Basically you need to run this over SSH or SSL to obtain any kind of security. Dropbox has security out of the box.
Dropbox also has: A GUI, a website UI, conflict resolution, support for folders, local sync. The list goes on.
As others say, this is very, very, very immature and incomplete.
I'd rather use Dropbox. Or `rsync`.