Skip to main content ↑ ↓
Recent Posts
91
Feature Discussion / Re: Attachment hashing
Last post by emanuele -
heh.
Unfortuantely, security from our side is always a concern.
In terms of complexity the attachments code is already (as Spuds said) quite a bunch of spaghetti rolled up randomly. If we add also some kind of "custom naming" on top of it, depending on security concerns of the owner of the forum... well, I already regret giving 3 options to organize folders. :-\
So we have to account for people that keep their attachments and caches open to the public.

That said, a base_convert doesn't really add anything to the address space unless I'm misunderstanding: if $file_id in your example if the attach_id of the database, then either it be the number from the db or the version in base 36, the potential for conflicts remain the same (that is... almost 0, because attach_id is an autoincrement, so I would not expect to have the same number returned twice... at least in mysql, in postgre since we use a function I would expect in some remote edge cases it may actually happen, but who knows, I'm not particularly knowledgeable of databases).

In terms of "debugging" it boils down to what and how you are debugging, if it's just to know if an attachment is created, you can check if a file with a certain attach_id is present. If it is it has to match the one in the database (where, incidentally, the hash is stored (file_hash), so if you need it it's just another round up of fetching the info from the attachments table).

Just challenging, of course. ;)
93
Feature Discussion / Re: Attachment hashing
Last post by ian -
If security isn't a concern, I would definitely suggest that naming the files base_convert($file_id, 10, 36).'.elk' gives a lot more address space, eliminates any chance of naming conflicts, makes debugging a bit easier, and only the file_id is required to locate the .elk file in the attachments folder which might help untangle things a bit. It just looked ugly to me when I was doing the conversion :)
94
Support / Re: Mark all read
Last post by emanuele -
This query should do:
Code: [Select]
replace into elkarte_log_boards
select s.value, m.id_member
from elkarte_settings as s, elkarte_members as m
where s.variable = 'maxMsgID';
I think.
95
Feature Discussion / Re: Attachment hashing
Last post by emanuele -
Yep, pretty much what has been said.
I would say that that the hashing was also to reduce the cases of naming conflicts? Dunno.

I think your case is an exception in respect to security measures. In most of the cases, the attachments directory is just in plain sight.
It's the same with the cache directory.
So I don't see this changing any time soon... What do you think @Spuds ?
96
Feature Discussion / Re: Attachment hashing
Last post by radu81 -
Quote from: Spuds  - 
Then the extension is also to prevent it from being seen as an executable or any file used by an installed program.  I think that is all the reasons @emanuele ?
 IIRC the extension was also added to avoid problems with Filezilla (as explained on SMF forums). Yep, I was also affected by this problem years ago and I lost some attachments and avatars. :(