Fork me on GitHub

FileShare Help  Bottom

  • I can't find a support forum for FileShare, so hopefully this is the best place.

    Trying to upload a file, I get this error: "Error! Sorry! Bad arguments passed to API function"

    AFAIK PHP is running as CGI

    RedHat linux 7.3
    Apache 1.3.27
    PHP 4.3.10
    MySQL 3.23.56

    pnfiles is 777. htaccess checks OK. Not sure what else to check.

    Comments so far:

    Would be nice to have sub-categories (can't see it, if it does already exist)

    How about being able to place the pnfiles folder away from public access. I think Photoshare does this. (not sure if that really improves security or not).

    Auto-add files already in pnfiles (using FTP to bulk upload files). Allows for protected download of files bigger than the PHP upload size.
  • AGlossop

    I can't find a support forum for FileShare, so hopefully this is the best place.


    Support requests are virtually nil, so a forum hasn't been warranted. Thanks for at least looking for "the right place" though. :) I'll split this thread into a "tips" type thread...

    First, get your PHP configuration settings. If the "Server API" is "CGI", there's no need to CHMOD the ../pnfiles/.. directory...though it won't hurt if you did... However, .htaccess does not work if your PHP is running as a CGI, which negates the best part of the module's security features. So it is recommended to run PHP as an Apache Module.

    Quote

    Allows for protected download of files bigger than the PHP upload size.
    This is a limitation of running PHP as a CGI. However, it can be easily overcome in PHP running as an Apache Module (and then using .htaccess).

    Next, ensure that your server has all of the following requirements (all of these things except #3 can be verified by viewing your PHP info):

    1. [*:84621fbe0d]PHP 4.3.9+ running as Apache
    2. [*:84621fbe0d]GD2 2.0.28+
    3. [*:84621fbe0d]CHMOD 777 ../modules/FileShare/pnfiles/..
    4. [*:84621fbe0d]file_uploads must be on
    5. [*:84621fbe0d]upload_max_filesize may need an increase to say, 8M
    6. [*:84621fbe0d]post_max_size should equal upload_max_filesize. In this case, 8M
    7. [*:84621fbe0d]session.use_trans_sid should be off (for better security, not FileShare related.)
    8. [*:84621fbe0d]register_globals should be off (for better security, not FileShare related.)


    So... If you're running your PHP as an Apache Module, you can use the following directives in your .htaccess file to help create the environment you need. Note that some hosts do not allow you to change some (or any) of these directives via .htaccess; if yours does not allow this, switch to DreamHost to get the absolute highest ! for your $.

    .htaccess

    Code

    php_flag session.use_trans_sid off
    php_flag register_globals off
    php_flag file_uploads on

    php_value upload_max_filesize 8M
    php_value post_max_size 8M

    <Files .htaccess>
    Order allow,deny
    Deny from all
    </Files>


    Hope it works out for you!
  • PHP version is 4.3.10 :) It's CGI, and nothing I can do about that (shared server, controlled by webhost) :(
    GD 2.0.28 installed :)
    file_uploads is ON :)
    upload_max_filesize is 8M :)
    post_max_size is 8M :)
    session.use_trans_sid is ON :(
    register_globals is ON

    I presume that you've confirmed that it won't work as a CGI :( And if I don't use htaccess, then there's no security if someone directly accesses the folder.
  • Sorry, no...

    To clarify: The module works with PHP running either way. The big difference is that when running PHP as a CGI, users can directly access your files ... but only if they can guess the filename.

    To illustrate, no matter which way you run your PHP, FileShare stores all uploaded files with random filenames such as 4klsxa8348adaeiu.jpg and sl23kd2j39ad2fa0.zip. Then, when a user downloads the file, it's automagically renamed (on the fly) to whatever custom name you specified at upload time. This effectively never gives users the target to the actual file.

    As a very skimmed example of what is happening, from upload to download, consider this:

    1. [*:0b94d4618e]You decide to upload "my_logo_300x100.gif" through FileShare.
    2. [*:0b94d4618e]You specify a custom "Suggested Name" (among other things) for the file and then upload it.
    3. [*:0b94d4618e]FileShare saves your file on the server with a randomized name like "58sl49dsa89n53d9.gif".
    4. [*:0b94d4618e]For users, the download link only shows (ie) "index.php?module=FileShare&func=download&fid=12"
    5. [*:0b94d4618e]The user clicks and the download is offered as "theSuggestedName.gif" with no path revealed.


    So to sum it up, FileShare will work with PHP running either way...and measures are taken to protect files in both situations.

    By running PHP as a CGI, you get "security through obscurity"...which isn't "real" security...but is quite helpful nonetheless. While this is not bullet-proof, it definitely makes it plenty harder to access your files directly, let alone know the contents of any given file, even with direct FTP access. Who's ever going to know that "dkg43k243989d2lk.zip" is actually the latest Paris Hilton video!?! (Though admittedly, that can be a double-edged sword!)

    By running PHP as an Apache Module, you get get the same benefit of "security through obscurity", but to that you add the strength of "real" server-sided security provided by .htaccess.
  • I did the htaccess check, and I did get the popup login window, so I thought that was a good thing.

    Not sure what else to try with this error. BTW I'm using FileShare v2 (as emailed to me on 26/2/6) and PN 0.762

    No problems running Photoshare, Gallery, and other modules that upload files to the server.

    If it's an "API error", then perhaps it's related to .762.
  • I've got it to work.

    You must fill in the title, description, and suggest name fields. If any are blank, you get the "API" error.

    Perhaps the error message could be more friendly, like "you forgot to complete field xxx". However I think you should be able to have a blank description. And the title and suggest name field should be able to just use the uploaded filename if left blank.
  • ...it's always the simplest thing... :D

    Glad it's working for you!
  • Are MSI files forbidden due to the GD utility?
  • No. It's simply not recognized as an allowed filetype. Adding new filetypes is easily achieved though. Look in the adminapi.php file ...

    You'll need to add the msi file extension and it's corresponding filetype to the FileShare_adminapi_get_allowed_exts() and FileShare_adminapi_get_supported_types() functions, respectively.

    Look at the code in those two functions...you'll see the "pattern", and how to add more filetypes, immediately. (If you don't know the technical filetype of an msi file, check google.)
  • I decided to compare FileShare with UpDownload. Not sure if anyone else has done so. They are both similar in their function.

    UpDownload (2.3)

    Allows for sub-categories :)
    Icons for each file type are provided :)
    Store folder can be changed (to non-public area) :D

    FileShare (0.2)

    No sub-categories :(
    Different graphic for each category :)
    Flename obfuscated :)

    Both provide security (link is a function, not a URL). I'm not sure how they compare further than that. I like the idea of being able to have the file store out of public reach.

    The next thing to investigate is permissions. I want to be able to easily set permissions. Sometimes set permissions based on category. Sometimes based per download file. Sometimes grant access to a group, and sometimes just to a specific user. I also want some categories available to all. Permissions in Postnuke seems to be quite powerful, but far from easy to use.

    If anyone else has compared the 2 modules, both very good, I'd like to know what decision you made, and why. At the moment, for me, UpDownload seems more suited to my needs. But only if permissions work as I need. ;)

This list is based on users active over the last 60 minutes.