[DigitalPoint] App for Cloudflare®

[DigitalPoint] App for Cloudflare® 1.8.4.1

No permission to download
Overview FAQ Updates (53) Reviews (20) History Discussion
digitalpoint said:
Well if you are getting an error in the error log, it means someone is trying to look at it.

Either way, it’s already an option that has been done on my end for the next version.
Click to expand...

Fair point. It's crawlers and evil bots that would be looking back that far. Really appreciate your hard work on this either way.

I'll need to migrate off wasabi to r2 at some point too.
 
Only just noticed you're doing signed urls now - that's a total game changer!

I don't use r2 (keep everything local on a dedicated) - but if ever I need to switch, this is awesome.

Cheers mate!
 
MattW said:
For the pre-signed URLs, Cloudflare isn't using HTTP/2 so it's reporting in GTMETRIX has quite a performance hit

View attachment 290562
Click to expand...
I forgot to follow up with you on this... A couple things:
  • There's no way there's a potential savings of 6.2s by switching to HTTP/2 as GTmetrix claims. Maybe if you had something like 10,000+ different HTTP requests on the page going over HTTP/1, but I suspect that's not the case here.
  • I talked to a Cloudflare engineer and at first they didn't think HTTP/2 or HTTP/3 were needed for R2. But we talked about the use case of using presigned URLs and he eventually agreed and at least was going to take the feedback to the R2 engineering team.
    Yeah, I see that WAF token authentication is a lot harder to use, especially in your use case. I'll take your feedback and see what we can do, but it'll likely take a while before this is fundamentally improved.
    Click to expand...
Obviously there's no promises or timeline, but at least it's on their radar.

He did turn me on to a different way to do short periods of read access to R2 objects that would ultimately be on your own domain (and then also be able to use HTTP/2 or HTTP/3), but it wouldn't work for zones on Free plans, so I'm thinking it's probably not worth the effort to code it if we can't do it for what I assume is a large subset of users.
 
digitalpoint said:
Hmmm... I haven't been able to replicate it on my end. Do you have a sample URL I could look at?
Click to expand...

It only happend with videos i think.

Sample urls:

Code: 
https://foropl.com/threads/el-maravilloso-y-definitivo-vidrio-de-los-hilos.81164/post-6313650
https://foropl.com/attachments/146452/
 
Rhodium said:
It only happend with videos i think.

Sample urls:

Code: 
https://foropl.com/threads/el-maravilloso-y-definitivo-vidrio-de-los-hilos.81164/post-6313650
https://foropl.com/attachments/146452/
Click to expand...
XenForo handles media a little differently... Video should never be stored as an attachment, it's always put into the data/video directory that's publicly accessible. That being said, I'll dig around a little and see if posts with uploaded video is doing something funky since video and audio are treated a little differently by XenForo internally.
 
@Rhodium I wasn't able to replicate it on my end, but I do see where we could add a better check if we should use presigned URLs since media attachments are handled differently than other attachments (their underlying data is stored in the public data area, not in internal_data).

If you go to the DigitalPoint\Cloudflare\XF\ControllerPlugin\Attachment.php file and change this:

PHP: 
if (\XF::options()->cloudflarePresignAttachments && !empty(\XF::options()->cfR2Bucket['internal-data/attachments']))

to this:

PHP: 
if (\XF::options()->cloudflarePresignAttachments && !empty(\XF::options()->cfR2Bucket['internal-data/attachments']) && substr($attachment->Data->getExistingAbstractedDataPath(), 0, 16) === 'internal-data://')

Does that fix it for you?

That adds an extra check to generate/redirect to a presigned URL only if the attachment data exists in internal_data (which should be all attachments except media).
 
digitalpoint said:
@Rhodium I wasn't able to replicate it on my end, but I do see where we could add a better check if we should use presigned URLs since media attachments are handled differently than other attachments (their underlying data is stored in the public data area, not in internal_data).

If you go to the DigitalPoint\Cloudflare\XF\ControllerPlugin\Attachment.php file and change this:

PHP: 
if (\XF::options()->cloudflarePresignAttachments && !empty(\XF::options()->cfR2Bucket['internal-data/attachments']))

to this:

PHP: 
if (\XF::options()->cloudflarePresignAttachments && !empty(\XF::options()->cfR2Bucket['internal-data/attachments']) && substr($attachment->Data->getExistingAbstractedDataPath(), 0, 16) === 'internal-data://')

Does that fix it for you?

That adds an extra check to generate/redirect to a presigned URL only if the attachment data exists in internal_data (which should be all attachments except media).
Click to expand...

Yep, this fixed the problem!

Thanks so much :whistle:
 
The API key page is not working and that's why I can't use the plugin. The requested page is not found error in the api key entry section.
 
enessafak said:
The API key page is not working and that's why I can't use the plugin. The requested page is not found error in the api key entry section.
Click to expand...
What URL are you talking about? In your admin area, or in Cloudflare's dashboard?

Everything I checked (both admin and in Cloudflare dashboard) seem to be working as expected...
 
So I did the full cutover to R2, rcloned my wasabi (s3 bucket) to cloudflare.

BTW, really amazing work here @digitalpoint, congrats on this addon.



Mostly went ok, noticing a few errors this morning:

One particular attachment is generating this on the front end:
  • Error: Call to a member function getExistingAbstractedDataPath() on null
  • src/addons/DigitalPoint/Cloudflare/XF/ControllerPlugin/Attachment.php:9
  • Generated by: Unknown account
  • Sep 17, 2023 at 5:56 AM

Stack trace​

#0 src/XF/Pub/Controller/Attachment.php(45): DigitalPoint\Cloudflare\XF\ControllerPlugin\Attachment->displayAttachment(Object(XFMG\XF\Entity\Attachment))
#1 src/addons/Truonglv/Api/XF/Pub/Controller/Attachment.php(32): XF\Pub\Controller\Attachment->actionIndex(Object(XF\Mvc\ParameterBag))
#2 src/XF/Mvc/Dispatcher.php(352): Truonglv\Api\XF\Pub\Controller\Attachment->actionIndex(Object(XF\Mvc\ParameterBag))
#3 src/XF/Mvc/Dispatcher.php(259): XF\Mvc\Dispatcher->dispatchClass('XF:Attachment', 'Index', Object(XF\Mvc\RouteMatch), Object(Truonglv\Api\XF\Pub\Controller\Attachment), Object(XF\Mvc\Reply\Reroute))
#4 src/XF/Mvc/Dispatcher.php(115): XF\Mvc\Dispatcher->dispatchFromMatch(Object(XF\Mvc\RouteMatch), Object(Truonglv\Api\XF\Pub\Controller\Attachment), Object(XF\Mvc\Reply\Reroute))
#5 src/XF/Mvc/Dispatcher.php(57): XF\Mvc\Dispatcher->dispatchLoop(Object(XF\Mvc\RouteMatch))
#6 src/XF/App.php(2487): XF\Mvc\Dispatcher->run()
#7 src/XF.php(524): XF\App->run()
#8 index.php(20): XF::runApp('XF\\Pub\\App')
#9 {main}

Request state​

array(4) {
["url"] => string(59) "/media/c40c4fb8-bbc7-4830-9cfe-a3880a6129d1-jpeg.32889/full"
["referrer"] => bool(false)
["_GET"] => array(1) {
["/media/c40c4fb8-bbc7-4830-9cfe-a3880a6129d1-jpeg_32889/full"] => string(0) ""
}
["_POST"] => array(0) {
}
}




Also getting a healthy amt of the below, these look like legacy media.

  • ErrorException: [E_WARNING] fopen(/home/nginx/domains/mysite.com/public/internal_data/image_cache/153/153829-e61d08ca32fba9005fd255213f7be8fc.data): Failed to open stream: Permission denied
  • src/vendor/league/flysystem/src/Adapter/Local.php:157
  • Generated by: Unknown account
  • Sep 17, 2023 at 1:13 AM

Stack trace​

#0 [internal function]: XF::handlePhpError(2, '[E_WARNING] fop...', '/home/nginx/dom...', 157)
#1 src/vendor/league/flysystem/src/Adapter/Local.php(157): fopen('/home/nginx/dom...', 'w+b')
#2 src/vendor/league/flysystem/src/Filesystem.php(122): League\Flysystem\Adapter\Local->writeStream('image_cache/153...', Resource id #13, Object(League\Flysystem\Config))
#3 [internal function]: League\Flysystem\Filesystem->putStream('image_cache/153...', Resource id #13, Object(League\Flysystem\Config))
#4 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(431): call_user_func_array('League\\Flysyste...', Array)
#5 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(395): League\Flysystem\EventableFilesystem\EventableFilesystem->callFilesystemMethod('putStream', Array)
#6 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(71): League\Flysystem\EventableFilesystem\EventableFilesystem->delegateMethodCall('putStream', Array)
#7 src/vendor/league/flysystem/src/MountManager.php(615): League\Flysystem\EventableFilesystem\EventableFilesystem->putStream('image_cache/153...', Resource id #13, Array)
#8 src/XF/Util/File.php(204): League\Flysystem\MountManager->putStream('image_cache/153...', Resource id #13, Array)
#9 src/XF/Service/ImageProxy.php(258): XF\Util\File::copyFileToAbstractedPath('/home/nginx/dom...', 'internal-data:/...')
#10 src/addons/ThemeHouse/ImageOptimizer/XF/Service/ImageProxy.php(20): XF\Service\ImageProxy->finalizeFromFetchResults(Object(ThemeHouse\ImageOptimizer\XF\Entity\ImageProxy), Array)
#11 src/XF/Service/ImageProxy.php(105): ThemeHouse\ImageOptimizer\XF\Service\ImageProxy->finalizeFromFetchResults(Object(ThemeHouse\ImageOptimizer\XF\Entity\ImageProxy), Array)
#12 src/XF/Service/ImageProxy.php(39): XF\Service\ImageProxy->refetchImage(Object(ThemeHouse\ImageOptimizer\XF\Entity\ImageProxy))
#13 src/XF/Proxy/Controller.php(122): XF\Service\ImageProxy->getImage('http://i223.pho...')
#14 proxy.php(34): XF\Proxy\Controller->outputImage('http://i223.pho...', '7e5f6c7b2e9182d...')
#15 {main}

Request state​

array(4) {
["url"] => string(169) "/proxy.php?image=http%3A%2F%2Fi223.photobucket.com%2Falbums%2Fdd55%2Fmarkfulton%2FMosport%2520ALMS%2520July%25202012%2FP1060176.jpg&hash=7e5f6c7b2e9182d8b6491bede5e78d35"
["referrer"] => string(60) "https://www.mysite.com/threads/mosport.3025/"
["_GET"] => array(2) {
["image"] => string(92) "http://i223.photobucket.com/albums/dd55/markfulton/Mosport ALMS July 2012/P1060176.jpg"
["hash"] => string(32) "7e5f6c7b2e9182d8b6491bede5e78d35"
}
["_POST"] => array(0) {
}
}
 
Hmmm... looks like a gotcha when something specific is going on... you are using presigned URLs, allow media attachments (XenForo treats them a little different than a normal attachment) and you are using those within XenForo Media Gallery... If you go to the DigitalPoint\Cloudflare\XF\ControllerPlugin\Attachment.php file and change this:
PHP: 
if (\XF::options()->cloudflarePresignAttachments && !empty(\XF::options()->cfR2Bucket['internal-data/attachments']) && substr($attachment->Data->getExistingAbstractedDataPath(), 0, 16) === 'internal-data://')

to this:

PHP: 
if (\XF::options()->cloudflarePresignAttachments && !empty(\XF::options()->cfR2Bucket['internal-data/attachments']) && $attachment->Data && substr($attachment->Data->getExistingAbstractedDataPath(), 0, 16) === 'internal-data://')

Does that sort it out for you?

I'm not entirely sure if that's normal with XFMG or not (I don't have a license for it to check)... it could be a missing attachment data record in your database (at which point it's a broken attachment with no actual data that goes with it). Either way, the above thing should prevent the error by only trying to generate a presigned URL if there's a known attachment data record.

As far as the other "legacy" attachment error, that's most likely from someone trying to view an attachment that is broken (the underlying attachment itself is missing). There's an option under the Cloudflare options section to hide the error (enable advanced options)... but the better thing to do is either fix the attachment if you have the underlying data in a backup somewhere or just delete the attachment since it's worthless and it will give end-users an error anytime they try to view it (since you don't have the binary part of the attachment, they can't view it).
 
Last edited:
digitalpoint said:
Hmmm... looks like a gotcha when something specific is going on... you are using presigned URLs, allow media attachments (XenForo treats them a little different than a normal attachment) and you are using those within XenForo Media Gallery... If you go to the DigitalPoint\Cloudflare\XF\ControllerPlugin\Attachment.php file and change this:
PHP: 
if (\XF::options()->cloudflarePresignAttachments && !empty(\XF::options()->cfR2Bucket['internal-data/attachments']) && substr($attachment->Data->getExistingAbstractedDataPath(), 0, 16) === 'internal-data://')

to this:

PHP: 
if (\XF::options()->cloudflarePresignAttachments && !empty(\XF::options()->cfR2Bucket['internal-data/attachments']) && $attachment->Data && substr($attachment->Data->getExistingAbstractedDataPath(), 0, 16) === 'internal-data://')

Does that sort it out for you?

I'm not entirely sure if that's normal with XFMG or not (I don't have a license for it to check)... it could be a missing attachment data record in your database (at which point it's a broken attachment with no actual data that goes with it). Either way, the above thing should prevent the error by only trying to generate a presigned URL if there's a known attachment data record.

As far as the other "legacy" attachment error, that's most likely from someone trying to view an attachment that is broken (the underlying attachment itself is missing). There's an option under the Cloudflare options section to hide the error (enable advanced options)... but the better thing to do is either fix the attachment if you have the underlying data in a backup somewhere or just delete the attachment since it's worthless and it will give end-users an error anytime they try to view it (since you don't have the binary part of the attachment, they can't view it).
Click to expand...

Yep, that got rid of the front end error. Now rightly telling me attachment isn't there.
 
I've got a small issue with the API and I want to ask for some advice.

We changed to a VPS and made a dev duplicate. Without thinking that it's still the same API between the live and dev site, I went ahead and enabled the HTTP2 and HTTP2 Prioritization on the dev site. Enabling it worked, but when going back to CF's Settings in the ACP, it gave the following error:

DigitalPoint\Cloudflare\Api\Exception\Server: Server error: GET https://api.cloudflare.com/client/v4/zones/b0711e155017fa6b5921a7e3990a3b88/settings/h2_prioritization resulted in a 500 Internal Server Error response: { "result": null, "success": false, "errors": [ { "message": "speed_api: unknown_error" } ], "me (truncated...) in src/addons/DigitalPoint/Cloudflare/Traits/XF.php at line 90
  1. DigitalPoint\Cloudflare\Api\Cloudflare->request() in src/addons/DigitalPoint/Cloudflare/Api/Cloudflare.php at line 562
  2. DigitalPoint\Cloudflare\Api\CloudflareAbstract->makeRequest() in src/addons/DigitalPoint/Cloudflare/Api/Cloudflare.php at line 394
  3. DigitalPoint\Cloudflare\Api\CloudflareAbstract->getSettings() in src/addons/DigitalPoint/Cloudflare/Repository/Cloudflare.php at line 910
  4. DigitalPoint\Cloudflare\Repository\CloudflareAbstract->getZoneSettings() in src/addons/DigitalPoint/Cloudflare/Repository/Cloudflare.php at line 664
  5. DigitalPoint\Cloudflare\Repository\CloudflareAbstract->organizeSettings() in src/addons/DigitalPoint/Cloudflare/Admin/Controller/Cloudflare.php at line 49
  6. DigitalPoint\Cloudflare\Admin\Controller\Cloudflare->actionIndex() in src/XF/Mvc/Dispatcher.php at line 352
  7. XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 258
  8. XF\Mvc\Dispatcher->dispatchFromMatch() in src/XF/Mvc/Dispatcher.php at line 115
  9. XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 57
  10. XF\Mvc\Dispatcher->run() in src/XF/App.php at line 2487
  11. XF\App->run() in src/XF.php at line 524
  12. XF::runApp() in admin.php at line 13

I have disabled the complete add on on the dev site, but the errors remain of course on the live site. Do you know what to do in my case? Does this require a new API install?
 
It looks like whatever is doing on in unrelated to your dev site or what you did with it. I'm seeing the same error right now and I didn't change anything. A 5xx error is a server-side error (in the context of the API, that means on Cloudflare's side).

FWIW, the error is also happening in Cloudflare's dashboard. Go to your website -> Speed -> Optimization -> Protocol Optimization and you end up with the same speed_api: unknown_error and the inability to see or change the Enhanced HTTP/2 Prioritization setting.

The good news is it's nothing you did... the bad news is it's on Cloudflare's side, so going to have to wait until they resolve it (but with it also broken in their dashboard, I assume it's won't be long).
 
You must log in or register to reply here.

Similar threads

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