k,
Using the os module, re module and a custom-made validator, I managed
to generate a form containing upload fields that are labeled after the
pictures in the static/images folder and only accept files that have
the same name as uploads.
Furthermore, by customizing the form display to place a hide/show
<img> tag corresponding to its picture under each upload, I give an
easy way for the artist to save the pictures on his computer without
having the resort to downloads.
However, I think that this line of code in gluon ensures that I can't
have final control over the naming of the stored files once they are
uploaded (file: sql.py, class: Field, method: store):
newfilename = '%s.%s.%s.%s' % \
(self._tablename, self.name, uuid_key, encoded_filename)
So, I can't directly overwrite the pictures in the static/images
folder with the uploads (I can easily customize the field on
declaration to change the upload folder to be the right folder, but I
can't control the filename so its moot).
>From there, I see 2 clear options:
1) Add an option in sql.py so that I can specify a fixed filename
Pros:
-The code in my app will look better and will execute efficiently.
Cons:
-I'll have to go through a lot of the code in gluon to make sure my
addition doesn't break anything.
-Each time I upgrade web2py, I'll have to redo the change and double
check to make sure it doesn't break anything.
2) Add logic in my app to rename the web2py named file to the actual
name of the picture in the static/images folder.
Pros:
- Well, probably a lot less work for me in terms of coding time.
Cons:
- The code in my app will be messier.
- Seems like an additional step to undo the work of a feature that I
didn't really want.
I think solution 2 is probably the lesser of 2 evils.
btw, if I'm not the only nutcase who do all his html/javascript/css
himself and put placeholder pictures for an artist to fill, I guess I
could create a slice detailing my solution.
On Oct 7, 3:07 pm, Magnitus <eric_vallee2...@yahoo.ca> wrote:
> 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.
>
>
