internalDataAdapter visibility is set to public

[K a M a L]

Affected version

2.1,2.2

We've created an addon to serve attachments directly from S3 using S3 presigned URLs instead of routing through xenforo attachment controller .. we noticed that signed URLs keep working after expiry and after removing the signing secret .. checking the bucket, I found that attachments visibility is set to public ( bucket setting is set to private ) .. tracking the code I found the issue here

$internalData = new EventableFilesystem($internalDataAdapter, [
            'visibility' => AdapterInterface::VISIBILITY_PUBLIC
        ]);

I know file names have hashes that can keep them obscure in normal use cases, but this needs to be fixed

 

[Kirby]

This is "Working as designed"

As designed - Default visibility on internal-data and code-cache is public

\XF:FsMounts::loadDefaultMounts $internalData = new EventableFilesystem($internalDataAdapter, [ 'visibility' => AdapterInterface::VISIBILITY_PUBLIC ]); [...] $codeCache = new EventableFilesystem($codeCacheAdapter, [ 'visibility' => AdapterInterface::VISIBILITY_PUBLIC ]); This...

xenforo.com

 

[K a M a L]

This is "Working as designed"

As designed - Default visibility on internal-data and code-cache is public

\XF:FsMounts::loadDefaultMounts $internalData = new EventableFilesystem($internalDataAdapter, [ 'visibility' => AdapterInterface::VISIBILITY_PUBLIC ]); [...] $codeCache = new EventableFilesystem($codeCacheAdapter, [ 'visibility' => AdapterInterface::VISIBILITY_PUBLIC ]); This...

xenforo.com

Given the use case I explained .. this needs to be fixed .. I don't see a design issue here , it is kind of " we don't need to spend some development time here as long as it doesn't hurt"

 

[PaulB]

We ran into the same issue. The inability to easily override it via config.php seems like an odd choice. S3 provides a variety of powerful tools for granularly adjusting permissions; XenForo just throws all of that out the window for no obvious benefit. Even in the default, local filesystem use case, manually setting everything to public isn't likely to resolve permission issues because it doesn't change the owner.

That being said, there's nothing stopping you from extending XenForo's classes and overriding their Flysystem config; it's just cumbersome and less than ideal. Eventually, someone is going to be bitten by the defaults, particularly when combined with XFAws.

 

[K a M a L]

That being said, there's nothing stopping you from extending XenForo's classes and overriding their Flysystem config; it's just cumbersome and less than ideal. Eventually, someone is going to be bitten by the defaults, particularly when combined with XFAws.

Thanks , we already extended FsMounts to override loadDefaultMounts but I think the base method still needs to be fixed ..