XF 1.5 Protection of Data & Internal_Data Folder Files

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?
 
Sort by date Sort by votes
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.
 
Upvote 0 Downvote
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;
}
 
Upvote 0 Downvote
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.)
 
Upvote 0 Downvote
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?
 
Upvote 0 Downvote
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?
 
Upvote 0 Downvote
Mike said:
If you just want to have them be accessible via the RM, doesn't uploading them into the RM solve the issue?
Click to expand...
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.
 
Upvote 0 Downvote
James said:
Did you report that as a bug or issue to be looked into?
Click to expand...
Not yet, as it might be more like a "missing feature" than a bug.

James said:
As a workaround you can zip the .apk files and upload a zip?
Click to expand...
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?
 
Upvote 0 Downvote
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.
 
Upvote 0 Downvote
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.webp

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

xfrm_file_upload_error.webp

If I upload "com.filename.app.apk.zip" I do not get any console error and the upload works.
 
Upvote 0 Downvote
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.)
 
Upvote 0 Downvote
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.
 
Upvote 0 Downvote
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.
 
Upvote 0 Downvote
You must log in or register to reply here.

Similar threads

digitalpoint
  • Suggestion Suggestion
Make data & internal_data filesystem adaptor more granular
Replies
16
Views
2K
digitalpoint
digitalpoint
Cupara
Directory Writable Errors
Replies
5
Views
919
Cupara
Cupara
UMILE
  • Solved
XF 2.0 My INTERNAL_DATA folder has increased from 31GB to 150GB due to duplicate attached files
Replies
4
Views
820
UMILE
UMILE
C
  • Question Question
XF 1.5 data @ internal_data directories
Replies
5
Views
913
Paul B
P
D
  • Question Question
XF 1.4 Cannot Install (data + internal_data cannot write)
Replies
18
Views
2K
Deleted member 80444
D
Back
Top Bottom