19 replies to this topic

[Cris D.]

File Name: front-end File Manager
File Submitter: Cris D.
File Submitted: 27 Jan 2008
File Updated: 27 Jan 2008
File Category: Security

This snippet is based on the snippet uploadForm by Cris D and ShowFiles snippet by Ralph. Although similar to the upload form, this snippet is basically a whole module that requires little configuration to get it working.

USES:
It allows admin to set a folder, for uploading while controlling the filename, filetypes, file size, and custom messages. Uploaded files are instantly listed underneath the upload form as they are uploaded with a href link to download or (if logged in- delete) them.

CONFIGURATION DETAILS:
Permissions are set to NULL on installation by default, make sure you either authenticate the page or set perms=simple or perms=roles depending on your required security settings on your site.

An example of many of the parameters used in a snippet call:
[!frontendFileManager
?uploaddir=assets/uploads
&allowed_ext=jpg,bmp,png
&max_size=80000
&perms='simple'
&uploadDescription= your pdf files.
&type_of_file=picture
&blockedMessage=Log in to upload files.
!]

NOTES:
This snippet attempts to create to folder name that you set but due to some server settings, this may have to be done manually and CHMOD to 0777.

The snippet is configured to allow multiple upload forms and file lests per page.

All uploads are stored in the upload folder and all upload info stored in a dedicated table including:
upload user id, type of file, folder where stored, filename, file extention, timestamp.

Files can also be deleted from the same window: if logged in, a "delete" button appears beside the file and when deleted, deletes the corresponding row from the table as well as the file.

See in action here:

Click here to download this file

Edited by Ralph, 27 January 2008 - 03:28 PM.
modified snippet call formatting for better presentation

[bwoodsdesign]

I am using this snippet but I don't see the upload button / browse field. I would post the info here but due to security concerns I'd prefer to keep that private.

Here is what I did...

I created a folder in the /assets/ dir and called it "uploads" - I set the perms to 777

I set a new document within my etomite doc root, called "Upload files" - originally I put this in the Repository/Unpublished folder

I put the whole snippet call and Etomite parsed the variables to have '&' put wherever there was an ampersand, so I took out the variables and just put in the snippet call as follows, into the document:

[!frontendFileManager!]

Then I got a message that I was supposed to create a folder called 'uploads' for the snippet to work. So I created a folder OUTSIDE of the /assets/ dir (just Etomite root) and then the document showed "Filename File Size Date Uploaded" as links to sort the info but nothing else appeared.

Can you help me? This site is for a client who has the unfortunate Yahoo webhosting which so far has not allowed me to set Friendly URL's because the host thinks '.htaccess' is an illegal file, now this. Because of this host I cannot seem to use the usual File Manager / Manage files setup, so this snippet seems like the perfect end to that issue, but I cannot get it working.

Thanks for developing this, Cris! I hope it solves my problem for me. My end user does not wish to use an FTP client to upload images and I really do not want to use Xhinia (which has a nice and robust file upload) because when I do that on hosts I have no control over it seems to be an open invite to hackers.

Thanks

[Cris D.]

You will have to set your security permissions of who can upload and delete. Try setting the ?perms=simple in the snippet call, you will also need to log-in through the authenticate_visitor snippet to have access to the upload and delete buttons.

[Cris D.]

I put the whole snippet call and Etomite parsed the variables to have '&' put wherever there was an ampersand, so I took out the variables and just put in the snippet call as follows, into the document:

I would be interested in hearing more about this error... This sounds weird. Can you PM the error message if you are worried about personal site details going public?

[bwoodsdesign]

So essentially, this snippet requires the use of the authenticate_visitor snippet as well?

Did not know that, or see that in the notes for this snippet.

I will give it a try. As it stands right now I'm not using the authenticate_visitor snippet, so that may be why I can't see the upload/browse functions.

Thanks

You will have to set your security permissions of who can upload and delete. Try setting the ?perms=simple in the snippet call, you will also need to log-in through the authenticate_visitor snippet to have access to the upload and delete buttons.

[Cris D.]

You may also be able to upload through the snippet if the page is viewed from inside the manager. I havn't tested it this method for this snippet, but I know it has worked for some snippets requiring authentication if users don't have authenticate_visitor installed.

[bwoodsdesign]

How and where do I implement the authenticate_visitor snippet, in conjunction with this frontend file mgr one?

It is not clear to me. Also, I cannot seem to get the snippet to display the browse/upload function no matter if I'm in the manager and viewing it from there, or outside the manager. No difference. Just displays the

Filename File Size Date Uploaded

info.

Any help on this?

Thanks

[Cris D.]

You'll have to do a search the forums for the latest authenticate_visitor snippet. I don't know why it is not in the new snippet library (don't use the one in the old snippet library). Then install it as per the instructions. Place the snippet call on its own page and when you successfully log in, you will be able to view all authenticated pages and your upload_manager should just work!

[Ralph]

The most current version of authenticate_visitor is always available on my development website where you can copy and paste the code... A simpler authentication snippet, Login|Logout will also work... That one may or may not be in the snippet libraries, I haven't checked, but is posted here in the forums as well... Both snippets might benefit form some additional sanitizing of the form inputs for security purposes...

[Jordan]

Hi!

Frist, thanks for the snippet. The idea of merging upload and folder display is great and very convenient.

However, I have a little problem with it. I know it should hide the upload feature when the visitor is not authenticated, but in my case it is not working. If you want to see the problem:

http://jordanroy.com...index.php?id=44

Thanks,
Jordan

[Jordan]

Hi!

Frist, thanks for the snippet. The idea of merging upload and folder display is great and very convenient.

However, I have a little problem with it. I know it should hide the upload feature when the visitor is not authenticated, but in my case it is not working. If you want to see the problem:

http://jordanroy.com...index.php?id=44

Thanks,
Jordan

Update:

Nevermind, this was a cache problem.


Jordan

Edited by Jordan, 18 June 2008 - 02:30 PM.

[TedD]

I copied (several times) the 'authenticate_visitor' snippet from the website of Ralph but the snippet didn't work at all. Maybe a copy failure?

So I used the old 'authenticate_visitor' snippet (from the old snippetlibrary) and this snippet works fine with the 'frontendFileManager' snippet. I wonder if the old 'authenticate_visitor' is safe to use?

-------------
The permission part (& p e r m s = 's i m p l e' ) as parameter in the snippet call doesn't work properly (can the old 'authenticate_visitor' snippet cause this?).

$perms=isset($perms)? $perms:'simple'; //simple || roles || NULL default: NULL

"Testlink frontendFileManager snippet
user: tester
passw: testing (remove this settings after a while........)

Kind regards,
Ted

[Ralph]

@Ted

I make a lot of changes on my development site and some snippets may vary substantially from versions located in the Snippet Library... Many of the changes I make are to acommodate what works for me or for customer sites... To paraphrase from the first paragraph on my site, "Change is an every day ocurrance around here", pretty much says it all... Almost every piece of snippet code displayed on my personal sites is pulled directly from the snippets themselves so it reflects the actual active code that the site is currently using... It doesn't help that I just can't stop fiddling with every bit of code either...

[Cris D.]

The permission part (& p e r m s = 's i m p l e' ) as parameter in the snippet call doesn't work properly (can the old 'authenticate_visitor' snippet cause this?).

The frontEndFileManager tries to accomodate the variety of ways users apply permissions. I personally use role-based permissions, but for some it is overkill or too complex to manage. Here is a run down of what you need to consider when matching your method of configuration with the snippet parameters:
1) If you do not have visitor permissions enabled in the manaer config, you can set $perms=NULL (or leave out)-default setting. Everyone will be able to add, delete and upload to your site.
2) If you have simple permissions (when you log in with authenticate_visitor or other log-in snippet that sets $_SESSION['internalKey'] to an integer and if you have visitor permissions enabled, this is also taken into accoutn) then you have achieved simple permissions and if you want to give anyone access that can log in to upload and delete files, this is for you but the API checkPermissions() must return '1'-see API for more on this.
3) However, if you want to use role-based permissions or control who can upload to and delete from the page where the frontEndFileManager is, then you will need to: user roles and permission levels and * have the correct person authorised to log in and visit the page where he/she can then upload, and delete files. This method requires that you set the number of the role in the snippet call also AND that the person logged in belongs to the permission level of that role. It looks for $_SESSION['role'] and matches it with the roles you pass in the snippet.

As you can see, the more complex the permissions, the greater the chance of config error. However, authenticate_visitor does the job beautifully of loggin people in. the API checkPermissions() does a great job of identifying how your site is set up and who is trying to access the resource, and finallyFrontEndFileManager uses both those resources to control what to display. When you say the snippet call $perm="" doesn't work...
I would be starting VERY simple and going from there, beause when you start playing wth complex role and document-based permissions it gets very messy very quickly if your not careful.

Edited by Cris D., 20 June 2008 - 11:30 AM.

[darren]

quick question:

do all users see all files in the folder but only have access to delete their own files?

if so would it be possible to only display files for the authenticated user?

I think this is gonna work for a new site but need to look closer first...

[Ralph]

quick question:

do all users see all files in the folder but only have access to delete their own files?

if so would it be possible to only display files for the authenticated user?

I think this is gonna work for a new site but need to look closer first...

No, file management is not managed at the user level... The current code base doesn't have the fine grained resource authentication you have described... I can't even guarantee that future releases will go that far as authentication might be based on several plugin module options...

[Cris D.]

Now I'm not offering to write it, and etomite does have individual checks to see who is logged in - so the perrmissions checks are all there - just not applied to the individual files.

it wouldn't be too hard to implemenet this for files by:

Create a new folder dynamically to store files for a particlular user and name it by their internalKey, and when logged in display only thier folder.
or
On upload, prefex the file name with their internalKey, then when logged in, filter out any files that don't start with the users' <internalKey>filename.ext.

An alternative it to place a single instance of this on each page allocated for each user that you assign ownership to, each with it's own istance of frontEndFileManage and files stored in it's dedicated folder with the snippet pointing directly to it. This will be a slow process and will involve implementing fine grained permissions for documents in your site first - not always easy to get it right. If this method works, you could automate this method by using the save_content_internal snippet- but this is advanced.

I have actually implemented this myself where users create an account, and when they log in, can upload images and documents that they can then "publish" and sell - all from the front-end.

It's possible (all things are possible with etomite!), but as Ralph says - not out of the box with this snippet.

Failing that, I saw some 3rd part tools last week (while I was looking for an upload progress module) that do just what you are describing that may work with eomite with a kick and a nudge.

[PS] I just realised that all details including the uploading user, filename etc are stored in a separate table (manager_uploads) that is built as part of the snippet, you could easily retrieve your documents from that table instead and just query the ones for a set user.

Then change the getFiles function that retrieves the files from a set folder:

if(!function_exists('getFiles')){
function getFiles($dir, $sort, $sortasc, $datetime) {

and retrieve the files based on the table query instead.

Edited by Cris D., 04 November 2009 - 08:05 PM.

[darren]

I just realised that all details including the uploading user, filename etc are stored in a separate table (manager_uploads) that is built as part of the snippet, you could easily retrieve your documents from that table instead and just query the ones for a set user.

will be looking closer at that method...

is it necessary to set the user role in the snippet call? if so how ...

"...//set the roles in an array that will have access to this snippet to upload files
$roles= isset($roles) ? $roles:array(1) ;//set only for admin by default
//add more roles like this: ? $roles:array(1,2,3,4);..."

i've tried &roles=array(1), &roles=1 but neither work, and after thinking about it more it seems like we should just let the user authentication happen before displaying the page instead of at the snippet level. Is there a reason the snippet should authenticate the user one more time?

[Cris D.]

is it necessary to set the user role in the snippet call? if so how ...

I believe you just set &roles=1,2,3 in the snippet call.

The reason that the roles are checked is to conditionally display the edit and upload parts of the snippet, the other users only see the links to the files. Roles are not necessary, but I added it to make use of the checkPermissions() API that actually checks roles as well document permissions.

Roles is only going to work if your site is using them (ie you have created multiple roles, assigned groups to roles and documents etc. A default etomite installation has them turned off and only Admin (1) works.

I think the simplest method is to authenticate at the page -for sure, just click "authenticate" and leave the snippet wide open. You can easily ger side-tracked and bogged down in permissions, only mess with them to extend existing functionality. Don't try and implement permissions on a setup that does not work yet.

[darren]

for my use only 'members' will be able to see the page and my intent is to only display files that belong to that member...

for that reason i've set perms=0, and changed line 128 to

if($perms==0) $userId = $_SESSION['internalKey'];

, otherwise the member_uploads table wasn't logging the member internalKey.