[DigitalPoint] App for Cloudflare®

[DigitalPoint] App for Cloudflare® 1.8.2

No permission to download
I'm getting the following error:
Code:
Error: Call to a member function getBody() on array src/addons/DigitalPoint/Cloudflare/Traits/XF.php:146

#0 src/addons/DigitalPoint/Cloudflare/Api/Cloudflare.php(503): DigitalPoint\Cloudflare\Api\Cloudflare->parseResponse(Array)
#1 src/addons/DigitalPoint/Cloudflare/Api/Advanced.php(812): DigitalPoint\Cloudflare\Api\CloudflareAbstract->makeRequest('HEAD', 'attachments/120...', Array, true, 'internaldata-to...')
#2 src/addons/DigitalPoint/Cloudflare/League/Flysystem/Adapter/R2.php(195): DigitalPoint\Cloudflare\Api\Advanced->headR2Object('internaldata-to...', 'attachments/120...')
#3 src/addons/DigitalPoint/Cloudflare/League/Flysystem/Adapter/R2.php(83): DigitalPoint\Cloudflare\League\Flysystem\Adapter\R2->getMetadata('attachments/120...')
#4 src/vendor/league/flysystem/src/Filesystem.php(57): DigitalPoint\Cloudflare\League\Flysystem\Adapter\R2->has('attachments/120...')
#5 [internal function]: League\Flysystem\Filesystem->has('attachments/120...', Array)
#6 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(431): call_user_func_array('League\\Flysyste...', Array)
#7 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(395): League\Flysystem\EventableFilesystem\EventableFilesystem->callFilesystemMethod('has', Array)
#8 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(128): League\Flysystem\EventableFilesystem\EventableFilesystem->delegateMethodCall('has', Array)
#9 src/vendor/league/flysystem/src/MountManager.php(313): League\Flysystem\EventableFilesystem\EventableFilesystem->has('attachments/120...')
#10 src/XF/Entity/AttachmentData.php(228): League\Flysystem\MountManager->has('attachments/120...')
#11 src/XF/ControllerPlugin/Attachment.php(9): XF\Entity\AttachmentData->isDataAvailable()
#12 src/XF/Pub/Controller/Attachment.php(45): XF\ControllerPlugin\Attachment->displayAttachment(Object(XF\Entity\Attachment))
#13 src/XF/Mvc/Dispatcher.php(352): XF\Pub\Controller\Attachment->actionIndex(Object(XF\Mvc\ParameterBag))
#14 src/XF/Mvc/Dispatcher.php(259): XF\Mvc\Dispatcher->dispatchClass('XF:Attachment', 'Index', Object(XF\Mvc\RouteMatch), Object(Snog\Forms\XF\Pub\Controller\Attachment), NULL)
#15 src/XF/Mvc/Dispatcher.php(115): XF\Mvc\Dispatcher->dispatchFromMatch(Object(XF\Mvc\RouteMatch), Object(Snog\Forms\XF\Pub\Controller\Attachment), NULL)
#16 src/XF/Mvc/Dispatcher.php(57): XF\Mvc\Dispatcher->dispatchLoop(Object(XF\Mvc\RouteMatch))
#17 src/XF/App.php(2483): XF\Mvc\Dispatcher->run()
#18 src/XF.php(524): XF\App->run()
#19 index.php(20): XF::runApp('XF\\Pub\\App')
#20 {main}

array(4) {
  ["url"] => string(75) "/comunidad/attachments/whatsapp-image-2021-09-14-at-12-39-24-1-jpeg.208571/"
  ["referrer"] => bool(false)
  ["_GET"] => array(0) {
  }
  ["_POST"] => array(0) {
  }
}

At the same time, these two have come up as well because of the same attachment:
Code:
ErrorException: Cloudflare: String could not be parsed as XML / null src/XF/Error.php:77
Code:
ErrorException: Cloudflare: Invalid response, code: 499 / src/XF/Error.php:77

Could it be because of the filename containing many numbers and characters?
HTTP 499 is a network issue between your server and R2. Specifically your server closed the network connection to Cloudflare unexpectedly. The addon already retries once automatically, but if it happens again, it will fail and you will see that in the log. Usually it will fix itself on its own after whatever is causing network issues is resolved on your server’s network.
 
HTTP 499 is a network issue between your server and R2. Specifically your server closed the network connection to Cloudflare unexpectedly. The addon already retries once automatically, but if it happens again, it will fail and you will see that in the log. Usually it will fix itself on its own after whatever is causing network issues is resolved on your server’s network.
Maybe you can try to merge both errors into one. Not sure how the server couldn't communicate to CF api taking into account they have hundreds of servers
 
It’s not an issue that your server couldn’t communicate with Cloudflare, rather after communication started, the client-side (your server), sent a network packet unexpectedly to force an early disconnect. The underlying reason can be a ton of things (for example a switch being rebooted or IP address changing).

It’s a tough one to diagnose/pin down, as you would generally need assistance of admins that manage network equipment your server network traffic flows through.

Usually 499 errors sort themselves out as network issues are resolved, but if it doesn’t, you’ll want to contact your server administrators.
 
1) I've manually created subdomain for serving data bucket. Beside setting "External data URL" to that subdomain, is there anything else needed? I've seen some special rule mentioned on the page when enabling it, but it would be applied when automatically add subdomain only.

2) Wondering is it safe to delete /data and /internal_data/attachments directories after enabling R2?

3) What is the most convenient way to backup R2 buckets to archive?
 
1. Honestly it’s going to be easier to let the addon do it all for you by disabling the data bucket and reenabling it and using the options it gives you to do all the things. You can of course do it all manually if you want, but if you are going to do it all manually including special rules it lets you do, you’re better off just letting it do it for you so you know it’s “right”. Either way, if it’s working for you, then whatever you setup manually should suffice (it’s not going to later break or anything if it’s working now).

2. As long as you are confident things are working and files have been moved, you can delete them.

3. You can use something like rclone if you feel the need to backup R2 data.
 
Tried disabling/reenabling, but auto configure won't work since subdomain is already present, it reports "10052: Domain already in use."

Not sure what "Create cache rule. Create a Cloudflare Cache Rule for the public subdomain that is optimized for XenForo" does.
 
Ya, you can’t create the same subdomain. Either delete it first or pick a different one if you want it to do the stuff it does.

But like I said, if you’ve manually done it and it’s working, it’s fine. It doesn’t later break somehow.
 
Deleted subdomain and then auto created things.

Noticed the new cache rule "Override cache for R2 bucket" having:
  • (http.host eq "<subdomain>")
  • Cache status: Eligible for cache
  • Edge TTL Override origin: 1 year
  • Status code TTL Override origin: 1 year
That was the missing part.

Many thanks.
 
I've just started getting this when logged into my ACP:

Code:
XF\PrintableException: Template admin:index error: Cloudflare zone not found: mattwservices.co.uk src/addons/DigitalPoint/Cloudflare/Traits/XF.php:167
Generated by: Matt May 12, 2023 at 6:21 PM

The zone is there and everything in terms of attachments etc is still working.

EDIT: might be my API token got messed up when I tried to edit it a couple of days ago to add another IP to the access list.
 
Does it give you a backtrace showing what triggered it by chance? Is it something new for you (like it just started happening but you didn’t install a new version of the addon or anything)?
 
Does it give you a backtrace showing what triggered it by chance? Is it something new for you (like it just started happening but you didn’t install a new version of the addon or anything)?
I edited my API token to add 2 new IP addresses to it, but in doing so, it removed all the functions except R2 Storage.
 
So to reproduce this, if you edit an API Token via the R2 interface:

1683912867590.webp

It's removes anything you've set by editing the API token via the Account function:

1683912914171.webp
 
Ya don’t edit your token via R2 interface. Not sure why it drops non-R2 permissions when you do that, but it does. The tokens used aren’t really R2 tokens, so I guess that’s why, but Cloudflare should prevent you from editing non-R2 tokens from the R2 interface imo.

Either way, everything good/sorted once you restored permissions to your token?
 
Ya don’t edit your token via R2 interface. Not sure why it drops non-R2 permissions when you do that, but it does. The tokens used aren’t really R2 tokens, so I guess that’s why, but Cloudflare should prevent you from editing non-R2 tokens from the R2 interface imo.

Either way, everything good/sorted once you restored permissions to your token?
Yeah, once I'd sorted the token out, the main admin dashboard came back.
 
Code:
#0 src/addons/DigitalPoint/Cloudflare/Api/Cloudflare.php(503): DigitalPoint\Cloudflare\Api\Cloudflare->parseResponse(Array)
#1 src/addons/DigitalPoint/Cloudflare/Api/Advanced.php(847): DigitalPoint\Cloudflare\Api\CloudflareAbstract->makeRequest('DELETE', 'attachments/21/...', Array, 0, 'internaldata-at...')
#2 src/addons/DigitalPoint/Cloudflare/League/Flysystem/Adapter/R2.php(157): DigitalPoint\Cloudflare\Api\Advanced->deleteR2Object('internaldata-at...', 'attachments/21/...')
#3 src/vendor/league/flysystem/src/Filesystem.php(237): DigitalPoint\Cloudflare\League\Flysystem\Adapter\R2->delete('attachments/21/...')
#4 [internal function]: League\Flysystem\Filesystem->delete('attachments/21/...', Array)
#5 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(431): call_user_func_array('League\\Flysyste...', Array)
#6 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(395): League\Flysystem\EventableFilesystem\EventableFilesystem->callFilesystemMethod('delete', Array)
#7 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(330): League\Flysystem\EventableFilesystem\EventableFilesystem->delegateMethodCall('delete', Array)
#8 src/vendor/league/flysystem/src/MountManager.php(533): League\Flysystem\EventableFilesystem\EventableFilesystem->delete('attachments/21/...')
#9 src/XF/Util/File.php(229): League\Flysystem\MountManager->delete('attachments/21/...')
#10 src/XF/Entity/AttachmentData.php(276): XF\Util\File::deleteFromAbstractedPath('internal-data:/...')
#11 src/XF/Mvc/Entity/Entity.php(1659): XF\Entity\AttachmentData->_postDelete()
#12 src/XF/Repository/Attachment.php(353): XF\Mvc\Entity\Entity->delete()
#13 src/XF/Cron/CleanUp.php(128): XF\Repository\Attachment->deleteUnusedAttachmentData()
#14 src/XF/Job/Cron.php(37): XF\Cron\CleanUp::runHourlyCleanUp(Object(XF\Entity\CronEntry))
#15 src/XF/Job/Manager.php(260): XF\Job\Cron->run(8)
#16 src/XF/Job/Manager.php(202): XF\Job\Manager->runJobInternal(Array, 8)
#17 src/XF/Job/Manager.php(86): XF\Job\Manager->runJobEntry(Array, 8)
#18 job.php(43): XF\Job\Manager->runQueue(false, 8)
#19 {main}
@digitalpoint, getting this error as well. Is it related to what you said above regarding HTTP 499?
 
Is it something ongoing or was it a one time thing? If it sorted itself out and isn’t happening now, most likely some sort of server connectivity issue that has since been fixed.
 
digitalpoint updated [DigitalPoint] App for Cloudflare® with a new update entry:

Better handling for some rare scenarios

  • Added check to make sure the site's hostname has at least one dot in it when determining Cloudflare zone ID (things like "localhost" are not valid Cloudflare zones)
  • Fetch up to 1,000 R2 buckets per account with API call instead of the default of 20
  • If API permissions get revoked on accident, don't throw exception about it on main admin index (admin index won't break if API permissions went away for some reason)

Read the rest of this update entry...
 
Top Bottom