I'm developing a web app that is going to have many files for news, photo galleries, users, products...also PDF documents associated to database records.
I'm going to store the images & docs in folders in the server and I'm wondering if it is a good practice or it is not necessary to encrypt those files & folders.
So, for example, for a photo gallery , let's say GalleryId = 233, I'm going to create the folder "~/Files/Galleries/233/" and store all the photos inside.
Also for a certain document, let's say "DocId = 22", I'd need the root "~/Files/Docs/22.pdf"...
Would it be necessary to encrypt those numbers so the users don't see the real Ids and see something like "aR2wdwewei"...?
Waste os time? Better to encrypt? Pros and cons?
Thanks in advance.
I suppose there is no difference between int ID or hash Id except one.
If someone wants to download all your server files with int name files it will be much more easier for him to get all data.
So if you want to protect yourself from this kind of "bruteforce download" - use GUID.
It's even better to create controller method that will return you any file you want. That way you will have one place where you can write access logs and restrict access if you need.
Related
I have a web app which uses nginx. Suppose it's in Rails, but it doesn't really matter.
I'm planning to have around a hundred of pictures/files uploaded every day by users. I don't want to use any custom solution for storying and uploading images and instead I want to manage that myself.
1) Is there an idiomatic place/path where I should store those images? Or will any path within the reach of nginx will work?
2) Should it be a separate folder from the one that I'm use for storying images for CSS?
3) How would I organize folders forest? That is, should it be something like /my_base_image_folder/{year}/{month}/{day}/{image_sequence_number}.jpg?
Or maybe /my_base_image_folder/{article_id}/{image_sequence_number}.jpg? Or should I put them in the same folder `/my_base_image_folder/{img_guid}.jpg?
And why?
4) What's a recommended solution for naming uploading files? GUID? Or a sequence number?
It all depends on your use case for consuming those images again. If you're planning to retrieve images uploaded by the users for those users on later sessions, ie., if your users have to browse through their images in your application, it's better to store it in a_public_folder/user_id_hashed/. If you're planning to retrieve images based on the uploaded time or date, it's better if you go with a_public_folder/year/month/day/... Make sure the public folder is accessible by your ngnix by using not-too-open permission, just to be safe. Also, naming the image files, a combination of timestamp and a small random hex should do I guess, no big deal.
I'm currently building into my app a method to allow users to provide images for their profile.
As part of the upload process I'll be creating a couple of different versions of the file for use in various different places in the system.
I am not going to store the images in a database as that just doesn't make sense to me. They will be served up by IIS and I also want to structure it in such a way that it will make migrating it to a CDN in the future a lot easier.
My current plan is to assign each user a GUID or similar unique value that will be stored in the database as part of their profile information, so something like:
ProfileId 1 - UserCode 628B3AF30B0F48EA8D61778084FC73C3
When a user uploads their profile image (or other data) I'll use the code to create a directory on the web server, for instance:
"~/userimages/628B3AF30B0F48EA8D61778084FC73C3/"
Then I'll store a few images in here like:
"~/userimages/628B3AF30B0F48EA8D61778084FC73C3/profilephoto160x160.jpg"
"~/userimages/628B3AF30B0F48EA8D61778084FC73C3/profilephoto25x25.jpg"
This should then make the process of recreating valid urls to the correct images both not hard coded anywhere nasty (like a profile image url in the database) and should make it a predictable process, something like:
var profileImgurl = BaseImageFolder + profile.UserCode + "profilephoto160x160.jpg"
I have no experience of CDN and was wondering if I'm creating any problems I'll struggle to solve later down the line when/if it gets migrated?
Does anyone see any nasty problems with this approach that I haven't thought of?
As far as I can tell people like google have a similar approach to this.
I believe this question is platform/technology independent, however I am using Ruby on Rails with the carrierwave gem.
Users upload documents to my site, and I need to keep them private. I am exploring the different options available to me, along with their advantages and disadvantages.
Option 1
Obfuscate urls to images to make them impossible to guess.
This would be relatively simple to implement and fast to serve up. However, if a url was made public by whatever means, security is lost.
Option 2
Have documents accessed through some sort of intermediate step that requires authentication. This would have improved security over option 1, but would place additional load on the server. A page containing previews of a number of uploaded documents would hammer the server.
Are there any other options available to me? Have I made any mistakes with my claims, or missed any important points?
I think the best option you have is to have a "key" for your documents. You can generate a key, with a certain lifetime, and when you go on /document/name/access_key, you find the record matching and return the file associated with the record. Never exposing the real URL.
I've been researching the best way to implement an application for my brother's business, and have been pretty stumped in terms of how to structure my application. The application will be run on iPad 2's deployed in the field, sometimes without readily available network access (due to spotty cell coverage in the area).
Here is the abstract on what it needs to do:
1) Load a template PDF file (its a contract to sign up for what is basically cable service) that has editable fields, such as:
a) Name b) Street address c) Dates
2) be able to collect a drawn signature (very similar to any credit card app, such as Square, etc), which is then overlaid onto the PDF.
3) Save the PDF, containing drawn signature and other edited fields, as a new file. Then, upload it to a backend server, using the name of the individual and date/time as meta data for sorting into specific folders.
Without this third aspect, an employee would have to spend 30 minutes to 2 hours a day categorizing all of the app submissions, so step number 3 is a pretty important aspect to the development, even though most of the work is outside the realm of objective C. Still, i need to send the PDF file off with as much information attached to it as I can...
I'd appreciate any guidance related to the best course of action in developing this. Are there any open source applications that you guys know of that I can reference to? I have searched Apple's Developer member center and Google to no avail.
How could i implement iText properly here? Is that even the best option?? It does digital signatures as opposed to those drawn with UI Kit...
Sounds like you should have a web service with a database for storing the meta information and the path to the generated PDF with the signature and other entries.
Your app would essentially generate the PDF, make a web service call and insert information such as the client's name, date/time, whatever else you want, and then the name or path of the PDF file. The PDF file would subsequently be uploaded to a designated location with a unique file name to prevent overwriting another PDF. You could formulate the name of the file off of the corresponding Key/Id of the record in the database or you could use a GUID as the filename and for good measure concatenate the EPOCH timestamp when the file was generated. Both approaches should guarantee filename uniqueness. Another possible file name scheme Device UUID+epoch timestamp, many options available.
If you have to actually edit the PDFs, it sounds like a pretty hard requirement. Another approach would be to show the user what they need to see (ie what they have to sign) and then generate the PDF with the signature and fields populated. Since you want to upload it anyway you would probably save yourself headaches if you offload this from the iPad and do it using a remote server (as Chris suggested) generating the PDF as you need it. I've been involved in helping out an iPad app development doing property inspections - it used Docmosis to do the document generation in preview and then in submitted forms. Hope that helps even though it's a few months down the track.
I have a number of documents (mainly Word and Excel) that I'd like to make available to users of my Rails app. However, I've never tried something like this before and was wondering what the best way to do this was? Seeing as there will only be a small number of Word documents, and all will be uploaded by me, do I just store them somewhere in my Rails app (i.e. public/docs or similar) or should I set up a separate FTP and link to that? Perhaps there's an even better way of doing this?
If they're to be publically accessable, you definitely just want to stick them in public somewhere. Write a little helper to generate the URL for you based on however you want to refer to them in your app, for cleanliness (and so if you do change the URL later, for example to bucket your files to keep your directory sizes under control, you don't have to change links all over your app, just in one place.
If, on the other hand, your files are only for logged-in users, you'll need to use something like send_file to do the job, or one of the webserver-specific methods like the X-Sendfile header to check the user is authorised to view the file before sending it back to them.
I would do as you suggested and put them in public/docs. If you are planning on making an overview/index page for the files and link directly to them it would be easier if they were stored locally instead of a remote FTP server. However, since you are the one who will be uploading and maintaining these files, I think you should go with the option that's easiest for you.