[DigitalPoint] App for Cloudflare®

[DigitalPoint] App for Cloudflare® 1.8.2

No permission to download
Overview FAQ Updates (51) Reviews (19) History Discussion
In those phrases cloudflare_firewall_filter_rule_registration_add_info & cloudflare_firewall_rule_registration_add_info Cloudflare is misspelled : Cloudlflare
 
Nicolas FR said:
IMPORTANT for existing users: The new R2 functions and control of new settings require some new permissions for the API Token you use. You can go to your Cloudflare API Tokens, edit the token you have and add the following permissions:
  • Account.Account Analytics: Read
  • Account.Workers R2 Storage: Edit
  • Zone.Bot Management: Edit
  • Zone.Cache Rules: Edit
You should have a total of 14 permissions for your API token at this point. If you don't have 14, you can check what you should have under XF Admin -> Options -> External service providers -> Cloudflare authenticationT
Click to expand...
Taken care of WELL before the add-on was installed. Not a neophyte in installing add-ons and checking instructions before doing so. ;)

Screen Shot 2023-01-06 at 8.02.47 AM.png


The point being I don't use the R2 features.... but when I install the latest add-on version I have problems... revert to the prior version and those issues become non-existent. And they appear to be directly related to serving of images (which the R2 function would involve). It was to the point I could not upload images and attach into a post Could that have been a setting I missed... yep.... but if so, that needs to be detailed in the documentaiton.
 
Last edited:
Not sure if this is something really obvious missing, but the bucket that was created by the addon for the data directory, is showing an error on the avatars.

1673014680844.webp

Domain access was automatically configured:

1673014716587.webp

But Public Access wasn't. Should that have automatically been set to Allows as well? I've since enabled it, but it's still showing the above error.


If I remove the cache buster string on the end, it loads:

1673014793410.webp

However, the original R2 setup I did using the XenForo addon works:

1673014845566.webp
 
Tracy Perry said:
Upgraded to this.. and MANY of my image links (like in sig and then even uploading images) had issues. I do NOT use R2 functions.. but apparently once you install the latest version of the add-on it expects that you do? Removing the add-on resolves the issue.. but then after installing 1.4 you apparently cannot regress back to 1.3 as a new install after removing 1.4. But then doing a refresh allowed me to re-install it.
So there is apparently an issue present.

Code: 
[*]ErrorException: Failed to write files for DigitalPoint/Cloudflare action, including src/addons/DigitalPoint/Cloudflare/Setup.php
[*]src/XF/Error.php:77
[*]Generated by: Tracy
[*]January 6, 2023 at 5:34 AM

Stack trace
#0 src/XF.php(219): XF\Error->logError('Failed to write...', false)
#1 src/XF/Job/AddOnInstallBatch.php(158): XF::logError('Failed to write...')
#2 src/XF/Job/AddOnInstallBatch.php(79): XF\Job\AddOnInstallBatch->stepInit(Object(XF\Timer))
#3 src/XF/Job/Manager.php(260): XF\Job\AddOnInstallBatch->run(8)
#4 src/XF/Job/Manager.php(202): XF\Job\Manager->runJobInternal(Array, 8)
#5 src/XF/Job/Manager.php(118): XF\Job\Manager->runJobEntry(Array, 8)
#6 src/XF/Admin/Controller/Tools.php(122): XF\Job\Manager->runByIds(Array, 8)
#7 src/XF/Mvc/Dispatcher.php(352): XF\Admin\Controller\Tools->actionRunJob(Object(XF\Mvc\ParameterBag))
#8 src/XF/Mvc/Dispatcher.php(259): XF\Mvc\Dispatcher->dispatchClass('XF:Tools', 'RunJob', Object(XF\Mvc\RouteMatch), Object(SV\UserMentionsImprovements\XF\Admin\Controller\Tools), NULL)
#9 src/XF/Mvc/Dispatcher.php(115): XF\Mvc\Dispatcher->dispatchFromMatch(Object(XF\Mvc\RouteMatch), Object(SV\UserMentionsImprovements\XF\Admin\Controller\Tools), NULL)
#10 src/XF/Mvc/Dispatcher.php(57): XF\Mvc\Dispatcher->dispatchLoop(Object(XF\Mvc\RouteMatch))
#11 src/XF/App.php(2483): XF\Mvc\Dispatcher->run()
#12 src/XF.php(524): XF\App->run()
#13 admin.php(13): XF::runApp('XF\\Admin\\App')
#14 {main}
Request state
array(4) {
  ["url"] => string(24) "/admin.php?tools/run-job"
  ["referrer"] => string(153) "https://astrowhat.com/admin.php?tools/run-job&only=addOnInstallBatch44&_xfRedirect=%2Fadmin.php%3Fadd-ons%2Finstall-from-archive-complete%26batch_id%3D44"
  ["_GET"] => array(1) {
    ["tools/run-job"] => string(0) ""
  }
  ["_POST"] => array(3) {
    ["_xfRedirect"] => string(81) "https://astrowhat.com/admin.php?add-ons/install-from-archive-complete&batch_id=44"
    ["_xfToken"] => string(8) "********"
    ["only_ids"] => string(5) "39317"
Click to expand...
It should not do anything with R2 unless you actually enable it, so something else is going on. Are you using any fsAdapters defined in your config.php? If so, which?
 
MattW said:
Not sure if this is something really obvious missing, but the bucket that was created by the addon for the data directory, is showing an error on the avatars.

View attachment 279521

Domain access was automatically configured:

View attachment 279522

But Public Access wasn't. Should that have automatically been set to Allows as well? I've since enabled it, but it's still showing the above error.


If I remove the cache buster string on the end, it loads:

View attachment 279523

However, the original R2 setup I did using the XenForo addon works:

View attachment 279524
Click to expand...
The config looks okay, can you confirm the paths of the objects in your bucket are correct?

If you change the cache busting string (rather than remove it), does it work? Wondering if it’s a caching issue itself.
 
digitalpoint said:
The config looks okay, can you confirm the paths of the objects in your bucket are correct?

If you change the cache busting string (rather than remove it), does it work? Wondering if it’s a caching issue itself.
Click to expand...
Everything looked OK. I've deleted everything, and I've started it again. Just re-copying over the /data/ directory from the old bucket and will re-test.
 
MattW said:
Everything looked OK. I've deleted everything, and I've started it again. Just re-copying over the /data/ directory from the old bucket and will re-test.
Click to expand...
Want to send me a screenshot of some of the files in going into the data bucket (can send privately)? The file listing I in Cloudflare interface would work. If you are moving them the same way as the first time, I suspect it’s not going to be any different than the first time.
 
digitalpoint said:
Want to send me a screenshot of some of the files in going into the data bucket (can send privately)? The file listing I in Cloudflare interface would work. If you are moving them the same way as the first time, I suspect it’s not going to be any different than the first time.
Click to expand...
1673021755543.webp

That's what the new bucket structure looks like.
 
and my rclone command:

/usr/bin/rclone sync r2z22se:z22se/data/ r2z22se:z22se-data/ --verbose --transfers 10
 
Maybe it's working? I manually checked the URL you gave before where it would work without the cache busting and not work with, and it seems to be working both ways at this point:



Only thing I can think of is maybe it was requested initially before it was there, cached on Cloudflare's side and then subsequent try for that exact URL (with the same cache busting string that was cached), was served from cache. If that was the case it probably would have been as simple as updating the cache busting string by editing a CSS file or in the admin (just adding a space would do it).
 
Yeah, it does appear to be working now. I did also notice another issue, which might have been compounding it. I previously had the lscache plugin installed, which was disabled, but still had the caching settings in .htaccess (only noticed when I could see broken images as a guest, but then working when logged in). I've removed all that, and also purged all the cache with Cloudflare.

Just putting the internal_data/ folder into R2 now.
 
Tracy Perry said:
Taken care of WELL before the add-on was installed. Not a neophyte in installing add-ons and checking instructions before doing so. ;)

View attachment 279520


The point being I don't use the R2 features.... but when I install the latest add-on version I have problems... revert to the prior version and those issues become non-existent. And they appear to be directly related to serving of images (which the R2 function would involve). It was to the point I could not upload images and attach into a post Could that have been a setting I missed... yep.... but if so, that needs to be detailed in the documentaiton.
Click to expand...
It's not an API issue. The worst that would happen if someone didn't update their API permissions would be if you tried to use something that required permissions you didn't have, you would get an error about insufficient permissions. So no... you did not do something wrong even if you didn't give it the new permissions.

I've been looking at the error you received, and on the surface it looks like a normal permissions issue in the file system where the web server "user" didn't have write permissions (appears to just be during the install process). That being said, I'll assume it's not simply a coincidence and look at other possibilities.

One major change in particular with 1.4 is it adds the ability to have "sub-adapters" in XenForo's filesystem (allows just a certain folder to optionally be stored in it's own adapter). So even if it's not being used (if you didn't enable R2), the underlying functionality is available. I believe I implemented in a backwardly compatible way (and I haven't seen anyone else run into issues using R2 or not). But one thing to maybe check is if you have a different add-on that might be altering the XF\FsMounts in a non-standard (not backwardly compatible) way. If you have development enabled in your admin, and you check Development -> Class extensions, do you have any addons that extend the XF\FsMounts class by chance? If you don't have development enabled, can you think of any add-on you might have that does anything with the filesystem or filesystem adapters?
 
MattW said:
Yeah, it does appear to be working now. I did also notice another issue, which might have been compounding it. I previously had the lscache plugin installed, which was disabled, but still had the caching settings in .htaccess (only noticed when I could see broken images as a guest, but then working when logged in). I've removed all that, and also purged all the cache with Cloudflare.

Just putting the internal_data/ folder into R2 now.
Click to expand...

Honestly, I don't know what lscache, but the public subdomain for R2 (data.z22se.co.uk) isn't going to do anything on your server, so pretty sure an addon or .htaccess it couldn't affect anything on that subdomain. That subdomain is served exclusively by Cloudflare. You could unplug your server or blow up your data center and that subdomain would still work.
 
Typos: the bane of writers and programmers since time immemorial. :LOL: (I have done both writing and programming so know whereof I speak. Sadly.)
 
digitalpoint said:
Honestly, I don't know what lscache, but the public subdomain for R2 (data.z22se.co.uk) isn't going to do anything on your server, so pretty sure an addon or .htaccess it couldn't affect anything on that subdomain. That subdomain is served exclusively by Cloudflare. You could unplug your server or blow up your data center and that subdomain would still work.
Click to expand...
xenforo.com

Unmaintained - LiteSpeed Cache for XF2 - Community

Developed by LiteSpeed Technologies - the LiteSpeed Cache Plugin for XenForo 2 (LSCXF2) is a PHP-based plugin that communicates with your installation of LiteSpeed Web Server(LSWS) and its built-in page cache, LSCache. Because LSCache is built...
xenforo.com xenforo.com

It's working after removing that and purging the cache.
 
just wondering if image_cache folder should be on r2 as well. maybe not because there are not many http only images to worry about 🤔. noticed the errors in backend because the folder did not have proper permissions once i moved the data back from old r2 bucket to local server 😛
 
Although, I'm now getting flooded with these errors:

Code: 
GuzzleHttp\Exception\ServerException: Server error: `HEAD https://REMOVED.r2.cloudflarestorage.com/z22se-attachments/attachments/275/275044-e67803dd3cbfaf83d3906f37b872112a.data` resulted in a `500 Internal Server Error` response src/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113
Generated by: Unknown account January 6, 2023 at 5:12 PM
Stack trace
#0 src/vendor/guzzlehttp/guzzle/src/Middleware.php(65): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response))
#1 src/vendor/guzzlehttp/promises/src/Promise.php(204): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response))
#2 src/vendor/guzzlehttp/promises/src/Promise.php(153): GuzzleHttp\Promise\Promise::callHandler(1, Object(GuzzleHttp\Psr7\Response), NULL)
#3 src/vendor/guzzlehttp/promises/src/TaskQueue.php(48): GuzzleHttp\Promise\Promise::GuzzleHttp\Promise\{closure}()
#4 src/vendor/guzzlehttp/promises/src/Promise.php(248): GuzzleHttp\Promise\TaskQueue->run(true)
#5 src/vendor/guzzlehttp/promises/src/Promise.php(224): GuzzleHttp\Promise\Promise->invokeWaitFn()
#6 src/vendor/guzzlehttp/promises/src/Promise.php(269): GuzzleHttp\Promise\Promise->waitIfPending()
#7 src/vendor/guzzlehttp/promises/src/Promise.php(226): GuzzleHttp\Promise\Promise->invokeWaitList()
#8 src/vendor/guzzlehttp/promises/src/Promise.php(62): GuzzleHttp\Promise\Promise->waitIfPending()
#9 src/vendor/guzzlehttp/guzzle/src/Client.php(182): GuzzleHttp\Promise\Promise->wait()
#10 src/vendor/guzzlehttp/guzzle/src/Client.php(95): GuzzleHttp\Client->request('head', 'https://f1d5fd5...', Array)
#11 src/addons/DigitalPoint/Cloudflare/Api.php(863): GuzzleHttp\Client->__call('head', Array)
#12 src/addons/DigitalPoint/Cloudflare/Api.php(766): DigitalPoint\Cloudflare\Api->makeRequest('head', 'attachments/275...', Array, true, 'z22se-attachmen...')
#13 src/addons/DigitalPoint/Cloudflare/League/Flysystem/Adapter/R2.php(146): DigitalPoint\Cloudflare\Api->headR2Object('z22se-attachmen...', 'attachments/275...')
#14 src/addons/DigitalPoint/Cloudflare/League/Flysystem/Adapter/R2.php(71): DigitalPoint\Cloudflare\League\Flysystem\Adapter\R2->getMetadata('attachments/275...')
#15 src/vendor/league/flysystem/src/Filesystem.php(57): DigitalPoint\Cloudflare\League\Flysystem\Adapter\R2->has('attachments/275...')
#16 [internal function]: League\Flysystem\Filesystem->has('attachments/275...', Array)
#17 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(431): call_user_func_array('parent::has', Array)
#18 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(395): League\Flysystem\EventableFilesystem\EventableFilesystem->callFilesystemMethod('has', Array)
#19 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(128): League\Flysystem\EventableFilesystem\EventableFilesystem->delegateMethodCall('has', Array)
#20 src/vendor/league/flysystem/src/MountManager.php(313): League\Flysystem\EventableFilesystem\EventableFilesystem->has('attachments/275...')
#21 src/XF/Entity/AttachmentData.php(228): League\Flysystem\MountManager->has('attachments/275...')
#22 src/XF/ControllerPlugin/Attachment.php(9): XF\Entity\AttachmentData->isDataAvailable()
#23 src/XF/Pub/Controller/Attachment.php(45): XF\ControllerPlugin\Attachment->displayAttachment(Object(XFMG\XF\Entity\Attachment))
#24 src/XF/Mvc/Dispatcher.php(352): XF\Pub\Controller\Attachment->actionIndex(Object(XF\Mvc\ParameterBag))
#25 src/XF/Mvc/Dispatcher.php(259): XF\Mvc\Dispatcher->dispatchClass('XF:Attachment', 'Index', Object(XF\Mvc\RouteMatch), Object(XF\Pub\Controller\Attachment), NULL)
#26 src/XF/Mvc/Dispatcher.php(115): XF\Mvc\Dispatcher->dispatchFromMatch(Object(XF\Mvc\RouteMatch), Object(XF\Pub\Controller\Attachment), NULL)
#27 src/XF/Mvc/Dispatcher.php(57): XF\Mvc\Dispatcher->dispatchLoop(Object(XF\Mvc\RouteMatch))
#28 src/XF/App.php(2353): XF\Mvc\Dispatcher->run()
#29 src/XF.php(524): XF\App->run()
#30 index.php(20): XF::runApp('XF\\Pub\\App')
#31 {main}
Request state
array(4) {
  ["url"] => string(61) "/attachments/acdn-z22se-com_userpix_1125_cdr_500_1-jpg.19474/"
  ["referrer"] => bool(false)
  ["_GET"] => array(0) {
  }
  ["_POST"] => array(0) {
  }
}

The file being called exists in R2
1673025343692.webp
 
Chromaniac said:
just wondering if image_cache folder should be on r2 as well. maybe not because there are not many http only images to worry about 🤔. noticed the errors in backend because the folder did not have proper permissions once i moved the data back from old r2 bucket to local server 😛
Click to expand...
It's one of the subfolders I was on the fence about. Here's why...

In theory, the image cache could be read/written to a lot, but the files are short lived, which means someone could run up their billable events quickly in Cloudflare (someone pops in 10 images to a post and now every time that post is viewed, you get +10 class A operations). To me, it would make more sense if it was in the data folder vs. the private internal_data folder (every read is done by the XenForo application and it's not going to be cached at the edge). Putting internal_data/image_cache doesn't really save time/latency because XenForo serves it, so the end-user's http request would still go through XenForo, which in turn would fetch it from R2 on the backend). Kind of the same logic for me for oembed_cache (short lived cache that is in the private internal_data folder).

That being said... I've built the system in a way where someone could put whatever folders (or all of internal_data) into R2 via XenForo's standard config.php changes for filesystem adapters if they really wanted.
 
MattW said:
Although, I'm now getting flooded with these errors:

Code: 
GuzzleHttp\Exception\ServerException: Server error: `HEAD https://REMOVED.r2.cloudflarestorage.com/z22se-attachments/attachments/275/275044-e67803dd3cbfaf83d3906f37b872112a.data` resulted in a `500 Internal Server Error` response src/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113
Generated by: Unknown account January 6, 2023 at 5:12 PM
Stack trace
#0 src/vendor/guzzlehttp/guzzle/src/Middleware.php(65): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response))
#1 src/vendor/guzzlehttp/promises/src/Promise.php(204): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response))
#2 src/vendor/guzzlehttp/promises/src/Promise.php(153): GuzzleHttp\Promise\Promise::callHandler(1, Object(GuzzleHttp\Psr7\Response), NULL)
#3 src/vendor/guzzlehttp/promises/src/TaskQueue.php(48): GuzzleHttp\Promise\Promise::GuzzleHttp\Promise\{closure}()
#4 src/vendor/guzzlehttp/promises/src/Promise.php(248): GuzzleHttp\Promise\TaskQueue->run(true)
#5 src/vendor/guzzlehttp/promises/src/Promise.php(224): GuzzleHttp\Promise\Promise->invokeWaitFn()
#6 src/vendor/guzzlehttp/promises/src/Promise.php(269): GuzzleHttp\Promise\Promise->waitIfPending()
#7 src/vendor/guzzlehttp/promises/src/Promise.php(226): GuzzleHttp\Promise\Promise->invokeWaitList()
#8 src/vendor/guzzlehttp/promises/src/Promise.php(62): GuzzleHttp\Promise\Promise->waitIfPending()
#9 src/vendor/guzzlehttp/guzzle/src/Client.php(182): GuzzleHttp\Promise\Promise->wait()
#10 src/vendor/guzzlehttp/guzzle/src/Client.php(95): GuzzleHttp\Client->request('head', 'https://f1d5fd5...', Array)
#11 src/addons/DigitalPoint/Cloudflare/Api.php(863): GuzzleHttp\Client->__call('head', Array)
#12 src/addons/DigitalPoint/Cloudflare/Api.php(766): DigitalPoint\Cloudflare\Api->makeRequest('head', 'attachments/275...', Array, true, 'z22se-attachmen...')
#13 src/addons/DigitalPoint/Cloudflare/League/Flysystem/Adapter/R2.php(146): DigitalPoint\Cloudflare\Api->headR2Object('z22se-attachmen...', 'attachments/275...')
#14 src/addons/DigitalPoint/Cloudflare/League/Flysystem/Adapter/R2.php(71): DigitalPoint\Cloudflare\League\Flysystem\Adapter\R2->getMetadata('attachments/275...')
#15 src/vendor/league/flysystem/src/Filesystem.php(57): DigitalPoint\Cloudflare\League\Flysystem\Adapter\R2->has('attachments/275...')
#16 [internal function]: League\Flysystem\Filesystem->has('attachments/275...', Array)
#17 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(431): call_user_func_array('parent::has', Array)
#18 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(395): League\Flysystem\EventableFilesystem\EventableFilesystem->callFilesystemMethod('has', Array)
#19 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(128): League\Flysystem\EventableFilesystem\EventableFilesystem->delegateMethodCall('has', Array)
#20 src/vendor/league/flysystem/src/MountManager.php(313): League\Flysystem\EventableFilesystem\EventableFilesystem->has('attachments/275...')
#21 src/XF/Entity/AttachmentData.php(228): League\Flysystem\MountManager->has('attachments/275...')
#22 src/XF/ControllerPlugin/Attachment.php(9): XF\Entity\AttachmentData->isDataAvailable()
#23 src/XF/Pub/Controller/Attachment.php(45): XF\ControllerPlugin\Attachment->displayAttachment(Object(XFMG\XF\Entity\Attachment))
#24 src/XF/Mvc/Dispatcher.php(352): XF\Pub\Controller\Attachment->actionIndex(Object(XF\Mvc\ParameterBag))
#25 src/XF/Mvc/Dispatcher.php(259): XF\Mvc\Dispatcher->dispatchClass('XF:Attachment', 'Index', Object(XF\Mvc\RouteMatch), Object(XF\Pub\Controller\Attachment), NULL)
#26 src/XF/Mvc/Dispatcher.php(115): XF\Mvc\Dispatcher->dispatchFromMatch(Object(XF\Mvc\RouteMatch), Object(XF\Pub\Controller\Attachment), NULL)
#27 src/XF/Mvc/Dispatcher.php(57): XF\Mvc\Dispatcher->dispatchLoop(Object(XF\Mvc\RouteMatch))
#28 src/XF/App.php(2353): XF\Mvc\Dispatcher->run()
#29 src/XF.php(524): XF\App->run()
#30 index.php(20): XF::runApp('XF\\Pub\\App')
#31 {main}
Request state
array(4) {
  ["url"] => string(61) "/attachments/acdn-z22se-com_userpix_1125_cdr_500_1-jpg.19474/"
  ["referrer"] => bool(false)
  ["_GET"] => array(0) {
  }
  ["_POST"] => array(0) {
  }
}

The file being called exists in R2
View attachment 279530
Click to expand...
There's probably not a lot I can do about 5xx errors (those are server-side errors on Cloudflare's side). The API library I built does retry once if it gets a 5xx error, but it gives up if it gets it again.

That's (hopefully) something transient/temporary on Cloudflare's side. In all the testing and data migration I've done, I've only received a single 5xx error (which is what prompted me to have it transparently try again). Maybe something going on with Cloudflare's side because it's a new bucket somehow? Not sure to be honest. Is it something that's still happening?
 
You must log in or register to reply here.

Similar threads

N
[DigitalPoint] App for Cloudflare® - FRENCH translation
Replies
8
Views
852
Ozzy47
Ozzy47
digitalpoint
App for Cloudflare (appforcf.com)
Replies
12
Views
1K
securedme
securedme
Top Bottom