[DigitalPoint] App for Cloudflare® 1.8.2

[Rusty Snippets]

Just installed 1.70, site bricked.

An exception occurred: [ErrorException] [E_WARNING] Undefined array key "cfMediaCachingSeconds" in src/addons/DigitalPoint/Cloudflare/Listener/AppPubComplete.php on line 10

1. XF::handlePhpError() in src/addons/DigitalPoint/Cloudflare/Listener/AppPubComplete.php at line 10
2. DigitalPoint\Cloudflare\Listener\AppPubComplete::run() in src/XF/Extension.php at line 81
3. XF\Extension->fire() in src/XF/App.php at line 2994
4. XF\App->fire() in src/XF/Pub/App.php at line 478
5. XF\Pub\App->complete() in src/XF/App.php at line 2490
6. XF\App->run() in src/XF.php at line 524
7. XF::runApp() in index.php at line 20

 

[digitalpoint]

See:

[DigitalPoint] App for Cloudflare®

The cache purge when a new post happens it's a new thing (no more API calls are being made), it only moved to running on the backend vs. the front-end (before the end user would have to wait for the API call to be run, now they don't). Cloudflare allows 1200 API calls per rolling 5 minute...

xenforo.com

 

[Rusty Snippets]

What do you mean have we 'updated' it instead of just copy? I ftp'd em up, but now can't get in to update it.

 

[digitalpoint]

What's the exact error if you go to /admin.php?add-ons/ on your site?

 

[Rusty Snippets]

Oh, sorry, hadn't tried direct link! Fixed now.

 

[digitalpoint]

Oh, sorry, hadn't tried direct link! Fixed now.

FWIW, that error should only show if you are in debugging mode and you copied the files but didn't update yet. So hopefully end-users didn't see it (I assume you aren't letting end-users run with debugging mode on)

 

[Rusty Snippets]

FWIW, that error should only show if you are in debugging mode and you copied the files but didn't update yet. So hopefully end-users didn't see it (I assume you aren't letting end-users run with debugging mode on)

No, was not in debug mode.

 

[Chris2]

Oddly, on 1.7.0 and trying to activate guest page caching, when going through the sequence it won’t activate, just opens up another window overlay to start the sequence over. Image caching activates fine, however. Have had guest caching active in previous versions but deactivated prior. Tried a couple browsers to activate guest caching.

 

[digitalpoint]

digitalpoint updated [DigitalPoint] App for Cloudflare® with a new update entry:

Fix when enabling guest page caching

Fix for issue when trying to enable guest page caching (ends up in a loop). Only needed if you don't have guest page caching enabled and you want to enable it.

Read the rest of this update entry...

 

[digitalpoint]

Oddly, on 1.7.0 and trying to activate guest page caching, when going through the sequence it won’t activate, just opens up another window overlay to start the sequence over. Image caching activates fine, however. Have had guest caching active in previous versions but deactivated prior. Tried a couple browsers to activate guest caching.

Augh, gross. Fixed in patch update.

 

[Chris2]

Augh, gross. Fixed in patch update.

Thanks! Activates fine now.

 

[Shuya]

Getting a lot of these errors after the last update.

 

[digitalpoint]

Nothing changed with R2 in the recent updates. However, from the looks of the error, I would check that your server's time/date is correct. S3 (and everything compatible like R2) only allow a maximum 15 minute variation in the time the server making the request thinks it is and the actual time. It's a security thing to make sure if the HTTP request is intercepted, it can't be used later.

 

[Ivancas]

Nothing changed with R2 in the recent updates. However, from the looks of the error, I would check that your server's time/date is correct. S3 (and everything compatible like R2) only allow a maximum 15 minute variation in the time the server making the request thinks it is and the actual time. It's a security thing to make sure if the HTTP request is intercepted, it can't be used later.

The time is fine and in sync, we have verified this:
synchronised to NTP server (5.78.71.97) at stratum 3
time correct to within 35 ms
polling server every 1024 s

 

[digitalpoint]

The time is fine and in sync, we have verified this:
synchronised to NTP server (5.78.71.97) at stratum 3
time correct to within 35 ms
polling server every 1024 s

It doesn’t have to be that accurate, just within 15 minutes. Did you verify the actual time the server thinks it is (and not just that it’s synced to an NTP server)?

I suppose it’s possible that Cloudflare’s server’s are the ones with the wrong date/time set, but I feel like if that was the case, their error monitoring system would have seen the influx of R2 errors almost immediately can fixed it on their end in short order. Is it an error you are still seeing? I haven’t seen the error for any of my sites…

 

[Ivancas]

Did you verify the actual time the server thinks it is

Yes, it is:

 

[digitalpoint]

Is it something you are able to actively replicate? Like if you try to delete and avatar and upload a new one, are you getting the error? The function used to generate the time within the R2 request signing process is one of the most basic functions that PHP has. It's the time() function (and it doesn't take any parameters). So you couldn't even have a rogue bit of code overwriting what it would return somehow.

If you aren't getting it currently, then either the server's date/time was corrected or Cloudflare's server's was corrected. If it is still happening for you, it might be worthwhile to put together a quick test case showing the request signing process output.

 

[Ivancas]

Is it something you are able to actively replicate?

No, I already tried to upload/remove an avatar and couldn't replicate it.

 

[digitalpoint]

No, I already tried to upload/remove an avatar and couldn't replicate it.

Probably not worth worrying about then. We can't pull the HTTP request headers to show what was actually set when the request failed. But even if we could, all that would tell us is if it was your server with the wrong time or not. It was either your server or Cloudflare's server, and whichever side it was seems to have since corrected it's incorrect time, so there's not a lot to be able to fix at this point (it's already fixed).

Ultimately it has to do with the security mechanism built into the S3 signing request (R2 uses the S3 protocol) that protects against reuse of the signed portion of a request.

If you are really bored:

Authenticating Requests (AWS Signature Version 4) - Amazon Simple Storage Service

Use access keys to create a signing key and authenticate your request using AWS Signature Version 4.

docs.aws.amazon.com

Protect against reuse of the signed portions of the request – The signed portions (using AWS Signatures) of requests are valid within 15 minutes of the timestamp in the request. An unauthorized party who has access to a signed request can modify the unsigned portions of the request without affecting the request's validity in the 15 minute window.

TL;DR:
The date/time of the server making the signing request (your server) and Cloudflare's servers need to match (at least within 15 minutes of each other), if one side's date/time is wrong the request will fail with the error you saw.

 

[Chromaniac]

so not sure if this has been asked before. the addon does not seem to offer ip blocking option if you try to mark a user as spammer from /approval-queue/ page. thanks!