[DigitalPoint] App for Cloudflare®

[DigitalPoint] App for Cloudflare® 1.9.1.1

No permission to download
Overview FAQ Updates (63) Reviews (22) History Discussion
digitalpoint said:
All done in Cloudflare.
Click to expand...
So, if I click ban on digitalpoint, your IP address is then sent to CloudFlare for banning (the "You've been blocked" page)?

This may be out of your domain, but would that violate this Privacy Policy:
We use your information for making you an account on X and we will not share or release your information to any third parties without your consent.
Click to expand...
And XF's:
XenForo Limited will not sell, distribute or lease your personal information to third parties unless we have your explicit permission or are required by law to do so.
Click to expand...

As permission was not granted to release information? Should a section be added where we're allowed to send it to 3rd parties in the event of a ban, etc.?
 
frm said:
So, if I click ban on digitalpoint, your IP address is then sent to CloudFlare for banning (the "You've been blocked" page)?

This may be out of your domain, but would that violate this Privacy Policy:

And XF's:


As permission was not granted to release information? Should a section be added where we're allowed to send it to 3rd parties in the event of a ban, etc.?
Click to expand...
Ya, if it violates your terms of service, you can alter your terms of service or not use that function. There isn’t a way to both use it and not alter your terms of service if that’s part of your terms.
 
  • Like
Reactions: frm
Although Cloudflare knows the user’s IP before you do. It’s technically Cloudflare telling you their IP. So you are only telling Cloudflare to block an IP they first told you about… I mean if you really want to get technical.
 
digitalpoint said:
Ya, if it violates your terms of service, you can alter your terms of service or not use that function. There isn’t a way to both use it and not alter your terms of service if that’s part of your terms.
Click to expand...
Yeah, just checking t's and dotting i's. Wanted to make sure it was sending the IP to CloudFlare for blocking (releasing 3rd party information without consent) before having to rewrite the Privacy Policy/Terms of Service that it was, which would violate.

Thank you!

(I would suggest everyone following this thread to look at your default XF's ToS Privacy Policy and Terms of Service before banning someone with this)
 
digitalpoint said:
Although Cloudflare knows the user’s IP before you do. It’s technically Cloudflare telling you their IP. So you are only telling Cloudflare to block an IP they first told you about… I mean if you really want to get technical.
Click to expand...
Then why log IP addresses on your server if you're not going to send them back as a ban? It would only make sense if you saved the IP from a session from CloudFlare to your database, and then sent that back to CloudFlare for banning, that you would be in violation of the default terms because, although CF gave it to you, the user didn't give you permission to send it back.
 
frm said:
Then why log IP addresses on your server if you're not going to send them back as a ban? It would only make sense if you saved the IP from a session from CloudFlare to your database, and then sent that back to CloudFlare for banning, that you would be in violation of the default terms because, although CF gave it to you, the user didn't give you permission to send it back.
Click to expand...
I'm not lawyer, but I suspect it could be interpreted different ways. If a third party gives you info about a user (or more specifically an HTTP request), I'm not entirely sure giving that info back to the source you got it from really would count as "disclosing" to a third party, especially if there's no user identifiable info. It was in fact that third party that gave you the info to start with.

There's all sorts of info related to an HTTP request that just by the nature of the request being in existence has to be disclosed... IP address is one of those things. Every time your server fulfills an HTTP request, you are disclosing the receivers IP to a zillion servers along the network route without their "permission".
 
Here's what I gathered from ChatGPT (which is the closest we can get to a lawyer).
Recommendations for Legal Clarity
  • To minimize ambiguity, it would be advisable to update the ToS/Privacy Policy explicitly stating that essential security or infrastructure service providers (such as CloudFlare) may receive limited user data strictly for operational purposes, including blocking access or preventing abuse.
  • This provides greater transparency, enhancing compliance with data protection laws and mitigating potential legal risks.
Click to expand...
 
Ya… not saying don’t do it, but not something I’d care too much about personally. If the user doesn’t want their IP disclosed to third parties (including ones you have no relationship with), they need to not use IP addresses. An HTTP request (including IP address transients numerous routers and networks every time a request is made). And you are talking about disclosing it to the third party that gave it to you to begin with. If you are going to update your terms of service, what about you disclosing the IP address (by fulfilling the HTTP request) to numerous third party networks that weren’t the ones to give you the IP address to begin with?

I mean if you are really trying to cover yourself from every angle. 🤷🏻‍♂️
 
digitalpoint said:
Ya… not saying don’t do it, but not something I’d care too much about personally. If the user doesn’t want their IP disclosed to third parties (including ones you have no relationship with), they need to not use IP addresses. An HTTP request (including IP address transients numerous routers and networks every time a request is made). And you are talking about disclosing it to the third party that gave it to you to begin with. If you are going to update your terms of service, what about you disclosing the IP address (by fulfilling the HTTP request) to numerous third party networks that weren’t the ones to give you the IP address to begin with?

I mean if you are really trying to cover yourself from every angle. 🤷🏻‍♂️
Click to expand...
The part that makes it murky is the default Privacy Policy stating:
We may collect non-personally identifiable information about you in the course of your interaction with our site. This information may include technical information about the browser or type of device you're using. This information will be used purely for the purposes of analytics and tracking the number of visitors to our site.
Click to expand...
It doesn't state that it can be used for abuse measures, such as sending it to CloudFlare for blocking purposes.
 
frm said:
The part that makes it murky is the default Privacy Policy stating:

It doesn't state that it can be used for abuse measures, such as sending it to CloudFlare for blocking purposes.
Click to expand...
It also doesn’t say you are disclosing their IP address to any random network willing to route the HTTP request.

Like I said, you are worried about disclosing the IP to the third party that gave it to you to begin with. But you aren’t worried about disclosing the user’s IP address to random networks routing traffic? That seems like something more important to disclose than disclosing a bit of info to the entity that gave the info to you to begin with.
 
digitalpoint said:
It also doesn’t say you are disclosing their IP address to any random network willing to route the HTTP request.

Like I said, you are worried about disclosing the IP to the third party that gave it to you to begin with. But you aren’t worried about disclosing the user’s IP address to random networks routing traffic? That seems like something more important to disclose than disclosing a bit of info to the entity that gave the info to you to begin with.
Click to expand...
Just going to drop this in and update my Privacy Policy to reflect... Seems like it can violate various laws (including GDRP) if not explicit, even if the HTTP request came from CloudFlare.



Yes, even though CloudFlare initially provided the IP address, sending it back to CloudFlare for blocking is generally compliant, as long as you maintain transparent disclosures and appropriate contractual arrangements with CloudFlare.

While this scenario does not inherently violate privacy laws, compliance relies upon clear disclosures, valid legal bases for sharing data, and appropriate agreements with service providers. Failure to adequately address these areas may create legal vulnerabilities under various privacy regulations.

Under the General Data Protection Regulation (GDPR) (EU), IP addresses are considered personal data. To comply with GDPR, your organization must establish a lawful basis—such as legitimate interests—for sharing IP addresses with CloudFlare for security purposes. Additionally, your Privacy Policy must explicitly state that personal data may be shared with infrastructure providers for security reasons, and you must have a GDPR-compliant Data Processing Agreement (DPA) in place with CloudFlare.

The UK GDPR and Data Protection Act 2018 impose similar obligations, requiring transparent disclosures, clear justification under legitimate interests, and formal DPAs with providers like CloudFlare.

Under the California Consumer Privacy Act (CCPA)/California Privacy Rights Act (CPRA) (US), IP addresses qualify as personal information. Compliance necessitates explicitly disclosing in your Privacy Policy that IP addresses may be shared with service providers such as CloudFlare for operational security. Additionally, you must ensure contracts explicitly limit CloudFlare's use of shared personal information solely for necessary business purposes, prohibiting unrelated commercial uses.

The Federal Trade Commission Act (FTC Act) (US) prohibits deceptive practices, requiring your Privacy Policy and Terms of Service to accurately reflect actual data-sharing practices. Failing to transparently disclose the sharing of IP addresses with CloudFlare could constitute a deceptive act under FTC guidelines.

Canada's Personal Information Protection and Electronic Documents Act (PIPEDA) classifies IP addresses as personal information. Compliance involves clearly notifying users through your Privacy Policy about the operational necessity of sharing IP addresses with CloudFlare for cybersecurity and access management purposes, including clear definitions of the scope and limits of such sharing.

Lastly, several U.S. state privacy laws, such as the Colorado Privacy Act and the Virginia Consumer Data Protection Act, require explicit transparency in your Privacy Policy regarding the sharing of personal information with essential security providers like CloudFlare to remain compliant.
 
digitalpoint said:
Ya, I missed it, sorry... in the src/addons/DigitalPoint\Cloudflare\XF\Template\Templater.php file, if you change this:
PHP: 
if ($ipObject === null && is_callable('parent::filterGeo'))

to this...
PHP: 
if ($ipObject === null && method_exists(get_parent_class($this), 'filterGeo'))

Hopefully that should fix it for you? Stupid is_callable().
Click to expand...
This might be a better fix:
PHP: 
if (... && is_callable([parent::class, 'filterGeo']))

parent::class is supported from php 5.5+, and probably is nicer to use than get_parent_class($this)
 
Last edited:
Error: Template admin:user_ip_list error: Call to undefined method XenSoluce\HideBbCode\XF\Template\Templater::filterGeo() src/addons/DigitalPoint/Cloudflare/XF/Template/Templater.php:41
Generated by: MentaL Mar 27, 2025 at 1:34 PM
Stack trace
#0 src/XF/Template/Templater.php(1186): DigitalPoint\Cloudflare\XF\Template\Templater->filterGeo(Object(SV\LazyImageLoader\XF\Template\Templater), [invalid], false)
#1 internal_data/code_cache/templates/l1/s0/admin/user_ip_list.php(28): XF\Template\Templater->filter([invalid], Array, false)
#2 src/XF/Template/Templater.php(1799): XF\Template\Templater->{closure:internal_data/code_cache/templates/l1/s0/admin/user_ip_list.php:4}(Object(SV\LazyImageLoader\XF\Template\Templater), Array, NULL)
#3 src/addons/MaZ/AMP/Traits/Templater/XF22.php(52): XF\Template\Templater->renderTemplate('user_ip_list', Array, true, NULL)
#4 src/addons/MaZ/AUN/XF/Template/Templater.php(39): MaZ\AMP\XF\Template\Templater->renderTemplate('admin:user_ip_l...', Array, true, NULL)
#5 src/XF/Template/Template.php(24): MaZ\AUN\XF\Template\Templater->renderTemplate('admin:user_ip_l...', Array)
#6 src/XF/Mvc/Renderer/Json.php(86): XF\Template\Template->render()
#7 src/XF/Mvc/Renderer/Json.php(70): XF\Mvc\Renderer\Json->renderHtmlFallback('XF:User\\IpList', 'admin:user_ip_l...', Array)
#8 src/XF/Mvc/Dispatcher.php(471): XF\Mvc\Renderer\Json->renderView('XF:User\\IpList', 'admin:user_ip_l...', Array)
#9 src/XF/Mvc/Dispatcher.php(453): XF\Mvc\Dispatcher->renderView(Object(XF\Mvc\Renderer\Json), Object(XF\Mvc\Reply\View))
#10 src/XF/Mvc/Dispatcher.php(412): XF\Mvc\Dispatcher->renderReply(Object(XF\Mvc\Renderer\Json), Object(XF\Mvc\Reply\View))
#11 src/XF/Mvc/Dispatcher.php(66): XF\Mvc\Dispatcher->render(Object(XF\Mvc\Reply\View), 'json')
#12 src/XF/App.php(2826): XF\Mvc\Dispatcher->run()
#13 src/XF.php(806): XF\App->run()
#14 admin.php(15): XF::runApp('XF\\Admin\\App')
#15 {main}
Request state
array(4) {
["url"] => string(201) "/admin.php?users/domain.2000436353/user-ips&_xfResponseType=json&_xfWithData=1&_xfRequestUri=%2Fadmin.php%3Fusers%2Fdomain.2000436353%2Fedit&_xfToken=1743082490%2C037bc837a0a13ba6020f105850f8dbfe"
["referrer"] => string(68) "https://forum.domain.com/admin.php?users/domain.2000436353/edit"
["_GET"] => array(5) {
["users/domain_2000436353/user-ips"] => string(0) ""
["_xfResponseType"] => string(4) "json"
["_xfWithData"] => string(1) "1"
["_xfRequestUri"] => string(42) "/admin.php?users/domain.2000436353/edit"
["_xfToken"] => string(43) "1743082490,037bc837a0a13ba6020f105850f8dbfe"
}
["_POST"] => array(0) {
}
}
 
Im getting the same issue when accessing user IP data

Pauly

Post in thread 'Standard Library by Xon'

Updated a few addons to latest version this morning and now seeing this server error while running XF2.3.6

I am unable to see user IP addresses, member IP tab within ACP fails to load as does IP addresses in moderator menu on the front end

Not sure if this should be posted here or over on @digitalpoint cloudflare app pages as the error references both ?
Disabling either addon restores normal functionality, turn them both on together and errors return

Code: 
Server error log
Error: Template public:member_ip_list error: Call to undefined method...
 
MentaL said:
Error: Template admin:user_ip_list error: Call to undefined method XenSoluce\HideBbCode\XF\Template\Templater::filterGeo() src/addons/DigitalPoint/Cloudflare/XF/Template/Templater.php:41
Generated by: MentaL Mar 27, 2025 at 1:34 PM
Stack trace
#0 src/XF/Template/Templater.php(1186): DigitalPoint\Cloudflare\XF\Template\Templater->filterGeo(Object(SV\LazyImageLoader\XF\Template\Templater), [invalid], false)
#1 internal_data/code_cache/templates/l1/s0/admin/user_ip_list.php(28): XF\Template\Templater->filter([invalid], Array, false)
#2 src/XF/Template/Templater.php(1799): XF\Template\Templater->{closure:internal_data/code_cache/templates/l1/s0/admin/user_ip_list.php:4}(Object(SV\LazyImageLoader\XF\Template\Templater), Array, NULL)
#3 src/addons/MaZ/AMP/Traits/Templater/XF22.php(52): XF\Template\Templater->renderTemplate('user_ip_list', Array, true, NULL)
#4 src/addons/MaZ/AUN/XF/Template/Templater.php(39): MaZ\AMP\XF\Template\Templater->renderTemplate('admin:user_ip_l...', Array, true, NULL)
#5 src/XF/Template/Template.php(24): MaZ\AUN\XF\Template\Templater->renderTemplate('admin:user_ip_l...', Array)
#6 src/XF/Mvc/Renderer/Json.php(86): XF\Template\Template->render()
#7 src/XF/Mvc/Renderer/Json.php(70): XF\Mvc\Renderer\Json->renderHtmlFallback('XF:User\\IpList', 'admin:user_ip_l...', Array)
#8 src/XF/Mvc/Dispatcher.php(471): XF\Mvc\Renderer\Json->renderView('XF:User\\IpList', 'admin:user_ip_l...', Array)
#9 src/XF/Mvc/Dispatcher.php(453): XF\Mvc\Dispatcher->renderView(Object(XF\Mvc\Renderer\Json), Object(XF\Mvc\Reply\View))
#10 src/XF/Mvc/Dispatcher.php(412): XF\Mvc\Dispatcher->renderReply(Object(XF\Mvc\Renderer\Json), Object(XF\Mvc\Reply\View))
#11 src/XF/Mvc/Dispatcher.php(66): XF\Mvc\Dispatcher->render(Object(XF\Mvc\Reply\View), 'json')
#12 src/XF/App.php(2826): XF\Mvc\Dispatcher->run()
#13 src/XF.php(806): XF\App->run()
#14 admin.php(15): XF::runApp('XF\\Admin\\App')
#15 {main}
Request state
array(4) {
["url"] => string(201) "/admin.php?users/domain.2000436353/user-ips&_xfResponseType=json&_xfWithData=1&_xfRequestUri=%2Fadmin.php%3Fusers%2Fdomain.2000436353%2Fedit&_xfToken=1743082490%2C037bc837a0a13ba6020f105850f8dbfe"
["referrer"] => string(68) "https://forum.domain.com/admin.php?users/domain.2000436353/edit"
["_GET"] => array(5) {
["users/domain_2000436353/user-ips"] => string(0) ""
["_xfResponseType"] => string(4) "json"
["_xfWithData"] => string(1) "1"
["_xfRequestUri"] => string(42) "/admin.php?users/domain.2000436353/edit"
["_xfToken"] => string(43) "1743082490,037bc837a0a13ba6020f105850f8dbfe"
}
["_POST"] => array(0) {
}
}
Click to expand...
What version of PHP? I've not been able to replicate at, and honestly the code looks pretty simple... check if the parent method exists before it tries to call it (but for whatever reason your setup is saying the parent class exists when it doesn't).
 
Xon said:
This might be a better fix:
PHP: 
if (... && is_callable([parent::class, 'filterGeo']))

parent::class is supported from php 5.5+, and probably is nicer to use than get_parent_class($this)
Click to expand...
You of course were correct... not just "nicer", but turns out, actually necessary because of how XenForo's class extension/execution order system works. :)

Flat out cannot rely on get_parent_class($this) to give you the parent class. 😬
 
You must log in or register to reply here.

Similar threads

D
[DigitalPoint] App for Cloudflare® - FRENCH translation [Deleted]
Replies
9
Views
875
Ozzy47
Ozzy47
digitalpoint
App for Cloudflare (appforcf.com)
Replies
12
Views
1K
securedme
securedme
Back
Top Bottom