I am very new to this, Sorry if this is a naive question. I've been through the ruby tutorial for Dropbox API. Still confused on where should I start.
My situation:
I am running a copyshop. And usually my customers either bring their usb sticks OR upload to gmail then download in my shop OR upload to dropbox then print thier docs/pdfs/fotos.
And one day a customer ask me if I know dropbox. I say YES, I know it. And he ask me if it's possible to share a folder with him, then he can put his files into the folder at home, then come to my shop, open it and print, neat!!
But...Other clients also want to use this service, and they don't want their files exposure to other people (maybe private fotos, secret business plan, important letters...etc). The other problem is I want to make those who do not have dropbox also could upload files to my Dropbox folder that they can come and print.
Why use dropbox is because it's free for till 18G. And When the customer comes to print, I can remove the files, so 2-10G will be enough for 1-3 days buffering.
What I am thinking is to implement a website that allows people to upload DOCs/PDFs/Photos and save these files to my dropbox folder.
For people who have dropbox accounts, they will have a folder called copyshop in their dropbox folder, and they drop files as they usually do. And I will have a folder App/copyshop/ , each one puts files in their copyshop folder will appears in my dropbox as a sub-folder under my App/copyshop folder, e.g. App/copyshop/Tom , App/copyshop/Mary ...etc.
For non-dropboxers they can take advantage of uploading to my website, then save it to my dropbox folder.
Is this possible with Dropbox API? From the official statement:
The API provides methods to read and write from Dropbox securely, so your users can bring all their important files with them to your app. Any changes they make will be saved back to all their computers, tablets and mobile phones.
It looks like not a recommendation way to do it.
Thank you! Every reply is appreciate.
if you make a site to upload files there is no need for dropbox, just let them upload to a map that is available in the shop.
To make it safe with dropbox would be a lot of work, i suppose customers don't want their files exposed to others, only suitable for regular customers, for occasional customers the best method i can think of is let them make a public link of a dropbox file and send it to you.
Another drawback of dropbox is that the size of shared files is added to both the the sharer and the shared so you could get in trouble with the limits.
You could also make a script that monitors a public dropboxfolder and immediately on arrival moves the files to a safe location not accessible from others.
I suppose FTP would be better manageable, you could give big customers their own map and password and occasional users a just-write, don't read the upload of others security.
Answer from the dropboxer,
Yes, this would be possible. There are a number of ways you might do this, and the method you choose will be up to you, so I'll just touch on a few.
Without even using the API, you could have your customers enable and use this feature to send you a read-only link to any file or folder in their Dropbox:
https://www.dropbox.com/help/167
This isn't a shared folder exactly, but it sounds like it should be sufficient.
You could use the API to build an app that would essentially do 1, but help them along with it. Essentially, you would have them authorize your app, and then let them select a file or folder, on which you would call /files (GET) (or /shares if that is more convenient for whatever reason) to download or share the files.
Hope this helps!
Greg
Related
I'm looking for a way to have a separate download folder for each Slack channel.
Slack official app doesn't give this opportunity, and devs aren't looking to implement it.
Any idea on how to setup something like this?
Nope. I also tried same before. but in reality you can't do this.
A quick heck around is use shortcake naming culture. For example if you have folder for codebase you can name folder as cd_1, cd_2, cd_3. For server folders name as ser_1, ser_2, ser_3.
So by doing this you can get benefit of folder sorting. All same folder will be visible at same location.
I've got an OS X app that I'm distributing outside the App Store. Currently, users go to my website and download a .zip file which contains the code-signed app within. It's very important to me that users don't have to register or create accounts to use my app.
My problem is I'd like to build out referral codes into my app as a way to encourage sharing. Ideally the flow would be something like:
User A opens the app and goes to a menu option to get a unique referral link based on a UUID (to avoid collisions).
User B goes to the unique referral link and downloads the .zip, which is a specially crafted version of the app that contains the referral code. Magic referral behavior is unlocked for User B.
I'm not really concerned about users cheating the system since the code is open-source and the app is free. But since the app is code-signed I can't change it at all (and I definitely don't want to go down the rabbit hole of trying to get my Heroku server to inject a referral code and then re-sign the app), but I'm not above sneaky things like adding the referral code to the name of the app, re-zipping it on the server, and then having the app inspect its own name to extract the referral code.
That, of course, is ugly.* Are there other ways I can cleverly add the referral code to the file metadata? Or is there some completely different approach I can take to otherwise achieve my goal? No solution is too hacky!
* Ugly to the user, that is. We're way past the point of worrying about ugly architecture.
How about not zipping the app until the referral link is called. Generate an external file with the code and zip that with the app then redirect to download the newly created archive. This is relatively easy using server side scripting. You can embed the code in the file and name the file consistently every time so that when downloaded, the app looks for the file, extracts the code as necessary and deletes the extraneous file.
After some experimentation, it appears that among all of the metadata present on files, the only field that's reliably set on different systems (since my Heroku servers don't run OS X) and reliably preserved through the zipping process is the touch timestamp.
I haven't quite gotten the code to completion yet but the current plan is to have the server modify the timestamp of the .app before zipping, and then the program inspects its own timestamp to find its referral code.
If that doesn't work I'll probably go with #Jon's solution above.
Since this is my first time posting a question on stackexchange, please excuse me if I've not included anything. Suggestions for a better post are very welcome!
Background
I'm looking for a way to create a file:// link in e-mails with a specific purpose. In my company we're all using Macbooks with Outlook as our e-mail-client. As soon as a specific document is updated, I would like to be able to e-mail a colleague saying: "here is the to the file". My personal link would be: file:///Users/<MyUserName>/Dropbox/Filepath.ext. However, this does not evaluate correctly on my colleagues computer. I have made it to work with a manual username change, but I'm hoping that there is a way to automatically fill in the username of that person.
My Question:
How can I make the link in such a way that it will always refer to that user's specific user folder?
Resources explored
I've tried working with file://~/ but that always gives a 'can't find the document' error. I've tried googling it but Dropbox and other services only point towards URL-links or to their website. Stackexchange hasn't provided me with an answer so far (Internal links / ":file//" links is without answer). Searching for 'computer independent file links' haven't given me any solace either.
Any help would be greatly appreciated!
not sure if this is what you want. You can check the dorpbox API and read a bit about it. But an easier way might be IFTTT, a free tool which launch triggers. So basically you need to create a folder in dropbox for each user and then use this tool to make triggers for each user. You can send an email and include the new dropbox link and as well you can program the IFTTT to send a file://Users//Dropbox/USER_DROPBOX_FOLDER/{{FILENAME}} whenever a file is placed in his folder.
Say I need to track about 10 big files (each over 1G) over the the LAN shared folder, and if the files get modified/updated/overwritten, I need to upload those new files to ftp, and do some sort of notification like email.
But I don't need to version control for older files, so it won't inflate the repository.
How could be an easy approach to this? Since it need to keep monitoring the files, ftp protocol, email notification. Will make a C# program be a feasible way to do this? Or any suggestions? Thanks.
EDIT:
After checking around a couple version control large binaries threads in SO, it seems I don't need a version control system. Actually, I just need to keep checking the file metadata and once it's changed, upload to ftp and send out email. Not sure Mogware can disable backup old binaries?
Is there any other tools are feasible for this specific case? Thanks!
I'm in no way affiliated with the guys at Mogware, but there is a tool called "FileHamster" which is a personal revision tool, offering you to track file changes, call scripts after a file has changed etc. It also provides FTP upload.
We're having a spirited discussion about this at my workplace. We're talking about user uploaded images for a bunch of products, not images needed to display the basic site. I say "no way" but I'm curious what others think.
Update: Just to clarify. These are customer supplied images for products that they are entering/modifying.
I agree with 'no way'.
Anything that may change on the site through day-to-day use, or is editable by whoever administers the website I consider to be 'content'. This includes uploaded files and database content, both of which are backed up separately. Nothing on the website that is in version control changes once it's been deployed. Easier that way.
Other ways of asking if something should be in version control:
Do the images change?
Are the changes related to anything else?
Can mistakes be made?
Is traceability wanted/needed?
If the rest of the site is version controlled, version control the images.
If the images are generated, version control the generator.
Presumably, what you are talking about is content that would be classified as user data, as opposed to project files. That stuff, while important, does not need versioning - that needs a plain old backup mechanism.
I recently added a new project into a fresh SVN repository, and every time I look at the 'uploads' folder I realise how stupid I was to include that in the initial commit.
It seems like what you're talking about is content that is in (or perhaps will be) in a database. If a customer is supplying you a list of products as well as the pictures of those products, then that should all come from a database. In this case, I wouldn't because your database should be backed up, but not in the VCS.
If it is not, and your web site is static, then I would only because it is "part of the site."
If you feel you must revision it, put these resources out of the path of the main repository somehow, and then give it a dedicated repository just for that content.
You don't want everyone who has to check out code getting a copy of every image when they checkout or update, its slow, and pointless, and having them in your primary tree will just have more headaches than you can Imagine.
/common_ancestor
/project_code/ # repository a
/resources_dir/ # repository b
If you have to use symlinks or web-server magic to make this happen, then do that, but whatever you do, DON'T put content like that in your main repository.
As far as backups vs revisioning go, revisioning it like this does give you a slight ease if you're using SVN as your distribution method as well, that way if a developer needs a copy of the images for testing purposes, its relatively easy to get a relatively up-to-date set of them.
If you aren't going to expose the versioning to the customers, then what would be the point?
The customers are already free to use version control on their own end, before they submit the files. You may want to encourage them to do so.