1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

XF 1.5 Protection of Data & Internal_Data Folder Files

Discussion in 'XenForo Questions and Support' started by Freelancer, Sep 1, 2016.

  1. Freelancer

    Freelancer Well-Known Member

    How can I prevent people from having access to files in the data and internal_data folder if they know the URLs? For example if some registered user forwards the exact URL to someone not authorized?

    Is there a way to protect files from being accessed by unregistered users but let them be accessed by registered users?
     
  2. Mike

    Mike XenForo Developer Staff Member

    The internal_data directory you can block all access to. We include a .htaccess for it and our Nginx config (for friendly URLs) blocks it.

    The data directory is designed to be directly accessible, so you can't block it. I'd note that if someone knows the URL and wants to share the content, they can just download it and send it to people.
     
    Freelancer likes this.
  3. Freelancer

    Freelancer Well-Known Member

    I actually have an NGINX server. I made an extra folder in the internal_data folder. Can you give me a tip how to use the NGINX config you mentioned?
     
  4. James

    James Well-Known Member

    If you have friendly URLs enabled then it should block that directory as part of the same file I think Mike is saying.

    https://xenforo.com/help/friendly-urls/
     
    Freelancer likes this.
  5. Freelancer

    Freelancer Well-Known Member

    Friendly URLs are enabled and seem to work, but I can still access files in the internal_data folder directly when I paste the full URL into the browser while not logged in.

    Does this excerpt from the help pages have to be added extra?

    Code:
    location /xf/ {
        try_files $uri $uri/ /xf/index.php?$uri&$args;
        index index.php index.html;
    }
    
    location /xf/install/data/ {
        internal;
    }
    location /xf/install/templates/ {
        internal;
    }
    location /xf/internal_data/ {
        internal;
    }
    location /xf/library/ {
        internal;
    }
    
    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_pass    127.0.0.1:9000;
        fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include         fastcgi_params;
    }
     
  6. Mike

    Mike XenForo Developer Staff Member

    Code:
    location /xf/install/data/ {
       internal;
    }
    location /xf/install/templates/ {
        internal;
    }
    location /xf/internal_data/ {
        internal;
    }
    location /xf/library/ {
        internal;
    }
    These are the lines that block access to specific directories. (You'll need to adjust them to fit your paths.)
     
  7. Freelancer

    Freelancer Well-Known Member

    Okay, if this has not been added to the NGINX config, the blocks have no effect right? That would explain why nothing is blocked.
     
  8. James

    James Well-Known Member

    Yeah if your file is empty your directories have been publicly accessible. You're best adding it ASAP.
     
    Freelancer likes this.
  9. Freelancer

    Freelancer Well-Known Member

    So my server host has fixed this now. Thank you very much for the help.
     
  10. Freelancer

    Freelancer Well-Known Member

    Okay, now I have another problem... I can not link to download files that are in the "internal_data" folder... although logged in as user.

    Scenario: I want to have downloadable files in a folder inside the "internal_data" folder (like /internal_data/download/filename.*) that are linked to the XF Resource Manager. Now when I click download it shows "404 – Not found"... What I wanted was to protect the files from direct linking and only allow registered users to download them via Resource Manager... Is this possible?
     
  11. Mike

    Mike XenForo Developer Staff Member

    Nothing in the internal_data directory should ever be directly accessible. Anything in it has to be accessed via PHP. The data directory is the one that is directly accessible (without PHP).

    If you just want to have them be accessible via the RM, doesn't uploading them into the RM solve the issue?
     
  12. Freelancer

    Freelancer Well-Known Member

    That's where I started (and I should have mentioned it maybe...) But the specific files are ignored by the Resource Manager. They are Android App files that start to upload till the progress bar reaches 100% and then hang while the upload animation gif loops... I think that "com.appname.app.apk" might be a problem with XFRM... I was uploading the files into a folder as a workaround but now I am stuck. Any idea appreciated.
     
  13. James

    James Well-Known Member

    Did you report that as a bug or issue to be looked into?

    As a workaround you can zip the .apk files and upload a zip?
     
  14. Freelancer

    Freelancer Well-Known Member

    Not yet, as it might be more like a "missing feature" than a bug.

    I tried that too, until realizing that if users download the apps as zip directly to their phones they might have trouble. It's not a real good solution. What I want to achieve is that users are able to download and install the apps directly with their mobile devices. Maybe this is a good suggestion for a XFRM extension to support app downloads?
     
  15. Mike

    Mike XenForo Developer Staff Member

    We get to the root of the problem... :)

    There's nothing that would cause a particular type of file to be rejected in the RM. It's likely that the files are either too big and you need to configure some server variables or there's something else causing the file to be rejected on the server level.
     
  16. Freelancer

    Freelancer Well-Known Member

    I can assure I double checked the XFRM settings.

    The files are 32 MB and 28 MB and I allocated 40960 KB in the options and filled in the "apk" extension. With the apk extension alone the files are not recognized in the browser upload dialog. So I changed the setting to "app.apk". Then they are recognized and I can start the upload.

    The progress bar stops at 100% and then hangs while the gif animation loops infinitely (at least I haven't waited longer than five minutes).

    I also should mention that my board uses the HTML5 uploader instead of the flash uploader. I also uninstalled flash from my computer... I had no problems with it anywhere anytime before.

    My first guess would be the somewhat exotic file name construction "com.filename.app.apk". But when I compress it into a zip it is named "com.filename.app.apk.zip" and then can be uploaded. But I need it uncompressed since users will download it straight to their phones/tablets.

    But looking into the browser console I was surprised to see a SWF Alert...

    The app extension list

    app_extensions.jpg

    Now it gets interesting because when I upload the uncompressed file "com.filename.app.apk" I get the following error:

    xfrm_file_upload_error.jpg

    If I upload "com.filename.app.apk.zip" I do not get any console error and the upload works.
     
  17. Mike

    Mike XenForo Developer Staff Member

    Can you upload it as an attachment to a post?

    When you say you're using an HTML5 uploader, do you mean an add-on? (The default, non-Flash uploader isn't really what most people mean by an HTML5 uploader.)
     
  18. Freelancer

    Freelancer Well-Known Member

    I use the https://xenforo.com/community/resources/tinhte-html5-uploader.3130/ add-on.

    Tried to upload it to a post (before I copied the XFRM settings to "Attachments" options) but get the following error without a console error:

    error.jpg

    It would not upload it in the first place if the extension wasnt in the settings but I guess the after upload processing of the file gives the script a hiccup...
     
  19. Mike

    Mike XenForo Developer Staff Member

    That would be because "app.apk" isn't really the extension -- "apk" is what's needed.

    You'll need to disable that (and possibly other) add-ons to do the testing here. You have to take add-ons out of the equation.
     
    Freelancer likes this.
  20. Freelancer

    Freelancer Well-Known Member

    XenForo me.... :LOL: We found the problem...

    When I use "apk" alone, the file is not recognized and can not be uploaded. When I use "app.apk" the file is recognized and can be uploaded but without "apk" it will not be processed.
    So I filled in "app.apk" AND "apk" and BINGO, now it works as it should... So the conclusion is that uploading and processing seem to be two different things.

    Thanks @Mike for the help.
     

Share This Page