Posted by zewa on April 28, 2009 at 10:47am
Jump to:
| Project: | Filebrowser |
| Version: | master |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hi ...
As stated some time ago with a issue, i have a NTFS checking builtin with the old version of Filebrowser.
Now today I tried the current version and it's quite different code than earlier.
I'd like to ask if it would be possible to do a little modification in the code.
At the position right before downloading happens, it would be nice if a seperate function, let's call it _custom_permission($filepath)
could be called which would return a bool value. If TRUE download should continue otherwhise stop and send a drupal_message.
Hope you could build in that one it would save me a ton of time, cause I'd have to go through the whole code
and for the devel this should be a thing of some minutes
Greetings
Zewa
Comments
#1
The download process has no special right checking, it works like this :
- for the parent folder I get the file listing (the same I use for display).
- il the queried file is not in the list => 404
- else => download
I can isolate the code that check if a file is in ot out the list if this is what you need.
#2
ok well what I need to do is make some extra checkings if the file is NTFS protected.
Meaning following:
USER A is in following LDAP groups --> GROUP A, GROUP B
Downloadfolder structure:
MainFolder (No NTFS special rights)
|
|- Folder A (GROUP A Protected)
|- Folder B (GROUP B Protected)
|- Subfolder C (GROUP C Protected)
In this example USER A may only browse the first main folder and the Folder A/B.
If inside folder B he may not even see the Subfolder C in the directory Listing.
Also if the User enters the path to Subfolder C or a File inside it as a link, a checking must be done so he may not
see/download anything.
With the old version of Filebrowser I simply put around every listing, and filedownload:
if(_checkNTFS($thisFolder) == true)
{
}
else
{
ECHO ERROR
}
And that would be exactly what I need that ifs on the right places, with a custom function
that for begin should always send back TRUE.
We could name it _customCheck() so it could be used for any kind of custom checking for Security Aspects.
Greetings
Zewa
#3
we can implement a hook for this. Have a look at _filebrowser_load_files and tell me were should be the best place.
#4
Is it just me, or is anyone else noticing that filebrowser will not give access to anyone without access to admin node content? I went through the user permissions line by line, turning on/off each setting until a non-admin user was able to even access any directory with filebrowser. I'm currently running drupal 6.16, and swftools-6.x-3.x-dev.tar.gz dated mar 8, 2010.
I have the two default roles and my administrator roles set up. The authorized user has filebrowser permissions set to all enabled, as does the administrator role. But, unless a user has the administrator role enabled in their profile, they cannot access the filebrowser unless I enable administer node content and administer content type turned on. Any one have any idea what's going on with this?
#5
So, has anyone else had issues with having to give a user node administrator access before they can access directories made in filebrowser? I even set up a sandbox system, where I had only the filebrowser module (and required support files), and had the same exact problem. I could see the directories just fine, anyone without admin level permissions get access denied until I turn on node administer permissions.
#6
Sorry, no, it's not just you. Give a try to the last dev (as soon as it's preparedà or try to change your code like this
<?php
function filebrowser_access($op, $node, $account) {
if ($op == 'view') {
if (!user_access(FILEBROWSER_VIEW_DIRECORY_LISTINGS, $account)) {
return FALSE;
}
}
if ($op == 'create') {
if (!user_access(FILEBROWSER_CREATE_DIRECTORY_LISTING, $account)) {
return FALSE;
}
}
if ($op == 'update') {
if (!user_access(FILEBROWSER_EDIT_ANY_DIRECORY_LISTINGS, $account) || !(user_access(FILEBROWSER_EDIT_OWN_DIRECTORY_LISTINGS, $account) && ($account->uid == $node->uid))) {
return FALSE;
}
}
if ($op == 'delete') {
if (!user_access(FILEBROWSER_DELETE_ANY_DIRECTORY_LISTINGS, $account) || (user_access(FILEBROWSER_DELETE_OWN_DIRECTORY_LISTINGS, $account) && ($account->uid == $node->uid))) {
return FALSE;
}
}
}
?>
#7
Confirmed that code change fixes the issue (Note for others wondering, that goes in the filebrowser.module file, at the bottom of the file, you replace the function with the code above (omitting the PHP header and footers of course)
- Greywolf
#8
I was having this issue - anon users could not see the node, but the latest dev fixed it. Thanks ...
#9
#10
Automatically closed -- issue fixed for 2 weeks with no activity.