[DigitalPoint] App for Cloudflare®

[DigitalPoint] App for Cloudflare® 1.8.2

No permission to download
I should have been clear... not a realistic way to do it at the edge. Cache Keys still wouldn't be ideal because you are limited in scope as to what you can logic on (even for Enterprise customers which probably no one here is). It could be done with Workers, but yes... that gets cost prohibitive real quick if you are routing all your requests through Workers. Given an infinite amount of money, yes... you could do it. But not sure people are wanting to throw an infinite amount of money at something that isn't some insane benefit.
 
Hmmm... there's nothing in there that should require PHP 7.3 (at least not intentionally). Do you happen to have the exact error anywhere so I could sort it out?
 
If you go to Settings under that bucket in Cloudflare, the Connect Domain option is where you can give it a public URL manually.

I’ve seen a couple other Cloudflare accounts that aren’t able to do it automatically via the addon for some reason. But haven’t been able to replicate it or able to see it firsthand to try and debug, but you can do it manually.
I'll try it manually. But at least now I know it might not automatically work, and that I may not have misconfigured something else. I did recheck all the API token permissions and they are all set properly, just in case I missed one.

What should I point my data.mysite.com domain to? I would think it should point to the public Cloudflare bucket address? pub-1xxxxxxxxxxxxxxxxxxxxxxx.r2.dev


Upgrade to 1.5.2 fixed this...
 
Last edited:
I’ve seen a couple other Cloudflare accounts that aren’t able to do it automatically via the addon for some reason. But haven’t been able to replicate it or able to see it firsthand to try and debug, but you can do it manually.
Update! I just upgraded to 1.5.2, tried it with a new test bucket, and the automatic configuration worked OK. I'm seeing everything set up the way it is supposed to be, and now it's making sense.

I was using the 1.5.1-alpha version you sent to me privately, so whatever the issue was, it's working now.

EDIT: It only seems to work when creating a new bucket. Using an existing bucket, the automatic configuration is not working.
 
Last edited:
Enabled it. Attempted to login, got security error.

login:1
Failed to load resource: the server responded with a status of 400 ()

Login pop up/ajax did not work when enabled. XF gave me the Ooops security error occurred.

This was in Edge.

Disabled it for now.
 
Last edited:
Update! I just upgraded to 1.5.2, tried it with a new test bucket, and the automatic configuration worked OK. I'm seeing everything set up the way it is supposed to be, and now it's making sense.

I was using the 1.5.1-alpha version you sent to me privately, so whatever the issue was, it's working now.

EDIT: It only seems to work when creating a new bucket. Using an existing bucket, the automatic configuration is not working.
Got that sorted now too for next version. Was able to replicate that one on my end so it was easy enough to fix.
 
Enabled it. Attempted to login, got security error.

login:1
Failed to load resource: the server responded with a status of 400 ()

Login pop up/ajax did not work when enabled. XF gave me the Ooops security error occurred.

This was in Edge.

Disabled it for now.
If you have a test site somewhere with it enable, I could take a look. There's a lot of stuff in play, so if the site has custom JavaScript or other JavaScript related things happening, might be able to spot whatever it is.
 
If you have a test site somewhere with it enable, I could take a look. There's a lot of stuff in play, so if the site has custom JavaScript or other JavaScript related things happening, might be able to spot whatever it is.

I'll flip it to ON and PM you details if you want.

THanks.
 
I'm thinking out loud here.
  • For the data directory, when creating a new bucket, this sets up everything else at Cloudflare seamlessly, and fills in the external data URL in XenForo to match. All good!
  • When choosing an existing bucket, nothing is set up at Cloudflare. At first I wondered if this was done on purpose, as it may be assuming that we already have everything else set up for the bucket. Yet when I tried it in a test, the domain for the data bucket would not populate in the list. (I thought this might be a way to temporarily disable routing everything to the R2 bucket, but even that doesn't make sense.)
Anyhow...when the data subdomain is set up at Cloudflare, it takes a little while for the new domain to propagate through the Internet. It only took about five minutes here at my location (just checked--all good!), but worldwide it might take a bit longer. I remember back in the 90s when a new domain would take an entire 24 hours before it became visible!

Tip--to greatly speed up copying the files, using the rclone flag --transfers 20 (or other suitable number, for the number concurrent transfers) copied my data directory in only about 2½ minutes. All included, from the time I configured the bucket with automatic configuration, to the time the thumbnail images and avatars reappeared, it was only about a ten minute interruption at the most.

The forum is 100% set up with R2 now, and working with no issues. 👍

EDIT (took me a couple of hours to "send" my reply): looks like it is solved in the next version.

Thanks again for everything @digitalpoint!
 
I'm thinking out loud here.
  • For the data directory, when creating a new bucket, this sets up everything else at Cloudflare seamlessly, and fills in the external data URL in XenForo to match. All good!
  • When choosing an existing bucket, nothing is set up at Cloudflare. At first I wondered if this was done on purpose, as it may be assuming that we already have everything else set up for the bucket. Yet when I tried it in a test, the domain for the data bucket would not populate in the list. (I thought this might be a way to temporarily disable routing everything to the R2 bucket, but even that doesn't make sense.)
Anyhow...when the data subdomain is set up at Cloudflare, it takes a little while for the new domain to propagate through the Internet. It only took about five minutes here at my location (just checked--all good!), but worldwide it might take a bit longer. I remember back in the 90s when a new domain would take an entire 24 hours before it became visible!

Tip--to greatly speed up copying the files, using the rclone flag --transfers 20 (or other suitable number, for the number concurrent transfers) copied my data directory in only about 2½ minutes. All included, from the time I configured the bucket with automatic configuration, to the time the thumbnail images and avatars reappeared, it was only about a ten minute interruption at the most.

The forum is 100% set up with R2 now, and working with no issues. 👍

EDIT (took me a couple of hours to "send" my reply): looks like it is solved in the next version.

Thanks again for everything @digitalpoint!
Cloudflare DNS has a default TTL of 900 seconds (15 minutes). So the longest anything should take to fully propagate is 15 minutes. However, that really only applies to changes of an existing DNS record (where someone queries for the DNS record in the past, was told not to query again for 15 minutes). A new DNS record shouldn't be subject to that because there shouldn't be any stale queries out there of people querying for that subdomain before it existed, so it should happen right away (within a few seconds anyway).

If you were flipping it on and off with the same subdomain, you might have hit the 15 minute thing. Like you queried for it, results were stored in your DNS cache on your device/computer, then the DNS record was deleted and re-added and it got added with a different IP address you would have to wait 900 seconds from the original query for that to go stale.

But ya ultimately Cloudflare has a default TTL for DNS records of 900 seconds so even changing IP on existing DNS records should never take more than 15 minutes for everyone's previous queries to go stale.
 
@digitalpoint
I am not entirely sure (as I can't fully test it) but from looking at the code it seems like

Code:
XF.config=new Proxy(XF.config,{set:function(c,d,b){c[d]=b;$('a[href*="t="]').each(function(){let a=new URL($(this).attr("href"),XF.config.url.fullBase);null!==a.searchParams.get("t")&&(a.searchParams.set("t",b),$(this).attr("href",a.toString()))});return!0}});
actually introduces a CSRF vulnerability:

It updates any link that has a t parameter including
  • System-generated internal links where parameter t is smth. else (there is no guarantee that t is always the token, I think there is good chance that Add-ons use such a parameter for smth. entirely different)
  • Internal user-generated links without a previously valid t parameter
  • External links (either system oder user-generated) with a t parameter
Especially the last one seems kinda serious to me - it allows an attacker not only to trick a guest user into clicking a prepared link (to perform an action like changing style or language) but to actually get knowledge of a valid token (by tricking the victim to click a prepared external link, for example in a post or signature).

And thay may even be accidently and break those links (think of links to vBulletin 3 threads: showthread.php?t=<id>).
 
Last edited:
Yep, there’s some other potential issues as well. Having tokens as random(ish) parameters in URLs that don’t get updated with XenForo’s KeepAlive function is not only bad design from the beginning, it’s also problematic for those reasons trying to update them. I’ve been testing a slightly different method for updating them, but it’s not ideal either (although it’s better). I have a better solution, but am still trying to figure out if that option can be avoided because it requires a bigger JavaScriipt payload, but thinking there might not be a way around it.
 
Top Bottom