Same Vulnerabilities as G2
|
trbailey
Joined: 2007-04-16
Posts: 172 |
Posted: Sat, 2009-04-25 16:40
|
|
I hope you all take this in the spirit it's meant. A constructive criticism. After installing and fiddling with G3 again and again and yet again, I've noted a few issues that I consider basic severe vulnerabilities. 1. Adding mass files to this gallery is more clumsy and less likely to be successful than before. I do like the simple "handful" upload interface but if I have to import 10,000 photos from a directory tree, after all the fiddling it takes to discover it's not going to happen I'm typing "rm -rf g3" in a big hurry and looking for something that can import and maintain sync with existing directories as well as provide a mass import function that works. It's even worse when the issue has been addressed and ignored. Case in point, a simple, stupid, legal character in a file name like TCitroën_IDDS_register_1955-1962.flv hangs the import with no error. Also, the interface overloads or hangs the browser with only 1500 images when using "Add from server", preventing it from succeeding, again with no error displayed (the browser is hung, what good will a PHP error do me now?). What's it going to do with 10,000 photos? Which brings me to my second noted vulnerability. 2. Back in G2 one of my biggest complaints was the inability to import or rebuild photo data from a directory structure without "importing" it again, thereby loosing the all important user meta descriptions. I suggested an export (backup) function for metadata that could be used to keep most of those time and labor intensive meta descriptions should the gallery become irretrievably corrupt. In the G3 planning stages I brought this issue up and it was noted to be heard and apparently agreed with. Essentially the issue is separating a photo from it's meta descriptors. Now here I am looking at the same basic underlying data structure as G2, an sql database and it's "album" tree with no way to sync the two. When they get out of sync, and they will, you've provided no way to correct the issue. While having a database is important for security, users, and searching and rapid retrieval of files for slideshows and feeds, I think it's an inappropriate place to keep isolated metadata. But that's my opinion, apparently one that is not shared. Furthermore, If a single photo gets corrupted (as in a filename) on disk in g3 there is no way to correct it. I can't even delete the file from the gallery. It invariably causes one of those user-friendly Kohana error pages. Echoes of G2 and what I thought was one of the underlying reasons for a rewrite. While you can patch the code to deal with the "ë" in file names, syncing files on disk with an isolated database when the database contains metadata is a bit more problematic and IMHO, a severe vulnerability. One that I thought was being addressed and corrected in this version. And I haven't even addressed the nightmare of maintaining a consistent backup. And that is, to coin a phrase, "the crux of the biscuit". Suggested solution: -Tom |
|
Posts: 7994
1) Are you importing 10,000 photos from a tree very often? If so you should be using the server_add module, or some similar mechanism to add your photos. If you find an issue where a specific filename hangs the upload, please file a bug and attach the file that caused the problem and we'll fix it.
2) Ok, I hear your problem. It sounds like your suggested solution is that somebody write an integrity-checker module which checks the files on disk against what's in the database. That sounds like a fine idea to me. Would anybody like to write such a beast?