Something just occured to me. The admin app is probably a good template to look at for what I want to do (I practically never use it prefering to interact directly with my app's file structure so I didn't think about it).
If I'm feeling really paranoid about question 2, I guess I can always implement a read-write lock for the files (but I should probably look at the admin app first). btw, I find the admin app kinda cool, but I think the design is off in some ways. You have access to everything through the admin app (kinda like the old one-user of Windows). It'd be better if you could break down the access into several roles (kinda like modern renditions of Windows and Linux). Ex: Being able to define a 'Programmer' group and give it access to the controllers, modules, views and static files. Being able to define a 'Translator' group and give it access to the language files. Being able to define an 'Artist' group and give it limited access to the static files. Anyways, my 2 cents. On Oct 7, 3:44 am, Magnitus <eric_vallee2...@yahoo.ca> wrote: > I am in the process of securing the help of an artist for my project, > but he's a casual computer user (doesn't know ssh/scp) and I'm trying > very hard to make everything as painless and pleasant as possible for > him to secure his help. > > In order to do that, I decided to create a view that will allow the > artist to download and upload pictures in the "static" folder of my > app (similar in concept to the facility provided to translators for > the languages, except with more fine-grained access control). > > Question 1: > > My current strategy (security-wise) is: > > 1) Limit the associated controller to the artist's role > > 1 a) A strong and unchangeable password will be provided to the artist > (in a face-to-face meeting). > > 1 b) Everything will go through TLS. > > 2) Limit downloads/uploads to .png/.gif/.jpg files (main pitfall if > part (1) fails: not sure what would happen if a malicious user > uploaded a malicious script/binary as an image... my guess is not much > except for a very weird-looking picture for the users... possible > webside defiguration there as well). > > 3) I'd also limit the IP access to the artist's home IP, but his IP > will probably be dynamic. Maybe limit the area, I'll see. > > 4) The artistis account will be deleted once the work is done. > > Any blatant oversight or possible improvement to this model? > > Question 2: > > The pictures in the static folder are constantly being read-accessed > during web-page requests. > > My guessing is that not much will happen if the artist downloads an > image. > > However, any possible complications if the artist uploads (and thus > overwrites) one of the pictures while a page needing it is requested? > > Thanks in advance for the feedback.
