Re: [openupload-devel] New Plugin: account_expire
Status: Beta
Brought to you by:
tsdogs
|
From: Alessandro B. <ts...@br...> - 2009-06-04 16:50:43
|
Hi Jochen, sorry for the late reply. > Thanks for reviewing it and giving me feedback. Although, sorry to say, I'm > not entirely sure what you mean. Are you saying that I misused the plugin > system for administrating user data (should I have made a module?) Or do you > mean that plugins altogether where never meant as an enhancement of the user > (or other) administration? > No, I'm saying that the way OpenUpload is designed right now has not considered plugins to extend the user data. Which should be fixed in next version imho. > The way I interpreted it is that plugins can (or could or should) manipulate > all entities in the system (users, groups, ...) and not just files. > yep. > Please let me know if I can be of any assistance with making changes to > either the plugin or any other part of the system. > Well, the problem here is noted above. It's not correct to have to enable the plugin for the administrators in this case. > > Indeed I code on windows, my apologies for not catching the case sensitivity > of the filenames. It might have been more of a reflex, writing the directory > name in camelcase (-: > no prob. > > In the mean while, I've made progres on the group assignment of files. I > have managed to implement it using a plugin as well. I did have to make some > (very minor) changes to the base system to get it to work but, I'll write > you later today or tomorrow to with the patch and an explanation. > > > There is one potentially critical issue I noticed though: anyone can > download files without necessarily having the rights to them. When a user > has the right to download files and knows the id of a file in the system > (not necessarily one he has access to) he can still download it. I did not > find any check on ownership of the file in the whole download procedure > (downloadForm, downloadRequest and downloadConfirm). Any user with the > download rights can thus craft a request string > (http://localhost/~OpenUpload/www/?action=d&id=******) and proceed with the > download. > Because it was not meant to work this way. The captcha and the password (better), should be the protection to the file. Probably implementing a check on the file that only the users on that group can download that file is the way to go. (it's like an hidden password) I will discuss this in the next e-mail.... Alessandro |