IniLerm
Forum Replies Created
-
Forum: Plugins
In reply to: [Advanced IP Blocker] XMLRPC.php Still Being BlockedHi @thewatchman3,
We have just released version 8.8.1. This update includes a specific patch to ensure compatibility with XML-RPC clients like MarsEdit when 2FA or reCAPTCHA is enabled.
Action Plan:
- Update the plugin to v8.8.1.
- Enable 2FA on your user profile (if you disabled it).
- Ensure you have the “Allow Rule” active: Just to be 100% sure no other security layer blocks the connection, please keep (or create) the Advanced Rule we discussed:
- Rule Name: MarsEdit Whitelist
- Conditions:
- Request URI Contains xmlrpc.php
- AND User-Agent Contains MarsEdit
- Action: Allow (Bypass Security)
With the plugin updated and this rule in place, MarsEdit should connect flawlessly using your Application Password.
Please let us know if this finally resolves the issue! If it works, marking the topic as “Resolved” would be greatly appreciated.
Best regards,
Advanced IP Blocker Team
Forum: Plugins
In reply to: [Advanced IP Blocker] XMLRPC.php Still Being BlockedHi Greg,
I am sorry to hear that the issue persists. Since you are seeing a “Critical Error” message (Error 500) instead of a “Forbidden” message (Error 403), this means the plugin is encountering a PHP conflict or crash when MarsEdit tries to connect, rather than just blocking it.
To fix this, we need to know exactly what is crashing.
How to get the error log (Safely):
Please access your site files (via FTP or your Hosting File Manager) and edit the wp-config.php file in the root directory.
Look for define( ‘WP_DEBUG’, false ); and replace it with this block of code. This will enable logging to a file without showing errors to your visitors:
// ============================================================= // SAFE DEBUGGING (LOG ONLY, NO DISPLAY) // ============================================================= // 1. Enable debug mode define( 'WP_DEBUG', true ); // 2. Save errors to /wp-content/debug.log define( 'WP_DEBUG_LOG', true ); // 3. DO NOT show errors on screen (Critical for live sites) define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', '0' ); // =============================================================Next Steps:
- Save the file.
- Enable the plugin.
- Trigger the error with MarsEdit again.
- Go back to your files and look for a new file called debug.log inside the /wp-content/ folder.
- Open it and verify the last lines. You will see a “Fatal Error” message pointing to a specific file and line number.
If you can paste that error message here (removing any sensitive paths), I can likely provide a fix immediately.
Thank you for your patience!
Best regards,
IniLerm
- This reply was modified 7 months, 1 week ago by IniLerm.
Hi Alex,
Thank you for understanding!
About your Feature Request:
Please do start a new thread for that topic. It helps other users find answers and keeps the discussion focused.Quick preview for that new thread:
You can actually already export and import your Blocked IPs list!- Go to Security > Settings > Import / Export.
- Choose “Export Full Backup”.
- This JSON file includes your entire Blocked IPs database table. You can import this file into another site running the plugin to transfer your blocklist instantly.
If you are asking about importing external text lists (like from GitHub), that is a different story, and we can discuss the pros/cons in the new thread (spoiler: manual lists often cause false positives!).
See you in the new thread!
Best regards,
Advanced IP Blocker Team
P.S.
I tried to visit your site (swha.online) to check your console errors and give you a specific CSP example, but the “Right Click / Inspect Element” protection script you have installed prevented me from opening the Developer Tools.
If you need further help debugging your policy, you might need to temporarily disable that protection so we (or you) can see the browser console errors that tell you exactly what is being blocked.Hi Alex,
Thank you for the detailed suggestions. I see what you mean about breaking down the policy for readability.
Regarding Scenario 1 (UI Labels):
The plugin already provides generic “Custom Header” fields below the main ones. If you prefer not to use the dedicated CSP text area, you can simply leave it empty and use the “Custom Header” fields to define Content-Security-Policy or any other header manually.Regarding Scenario 2 (Merging Fields):
While merging multiple fields into one header programmatically is possible, it adds complexity and potential for errors (e.g., if a user wants to add a different type of header).
Currently, the industry standard for managing CSP (in plugins, Cloudflare, or server configs) is a single block of text because the policy is evaluated as a whole unit.CSP Guide:
Creating a universal guide for CSP is extremely difficult because every website uses different plugins, themes, and external services (Google, Facebook, Stripe, etc.). A policy that works for Site A will break Site B.
This is why we mark CSP as an “Advanced” feature. It requires the site administrator to audit their specific site’s resources using the browser console.For now, we recommend using online tools like Report URI to build/validate your string, and then pasting the final result into our plugin.
We will keep your UX suggestion in mind for a future redesign of the headers section!
Best regards,
Advanced IP Blocker Team
Hi Alex,
Thank you for the detailed references. I understand you want granular control over CSP Level 2/3 directives.
Technical Clarification:
I believe there is a misunderstanding about how the Content-Security-Policy header works in the HTTP standard.You do not need multiple header fields to implement complex policies. The standard requires all directives (script-src, style-src, frame-ancestors, report-uri, etc.) to be included in a single header string, separated by semicolons (;).
Example of a complex Level 3 Policy in one field:
default-src ‘none’; script-src ‘self’ ‘nonce-xyz’; style-src ‘self’ https://example.com; img-src *; media-src media1.com media2.com; frame-ancestors ‘none’; report-uri /csp-report;You can already do this right now:
In our plugin, simply use the main “Content-Security-Policy” text area (or one Custom Header field). You can paste a policy string of any length and complexity there. It supports all Level 2 and Level 3 directives perfectly.Why we won’t add 10 separate fields:
Sending multiple separate Content-Security-Policy headers (one per field) causes browsers to enforce the most restrictive intersection of all of them, which often breaks sites unintentionally and is not the standard way to deploy a policy.Recommendation:
Use a tool like Report URI’s Wizard to build your complex policy string, and then paste that single string into the plugin’s CSP field. That will give you the full power you are looking for.Best regards,
Advanced IP Blocker Team
A Starter Example (Template):
Here is a common policy that covers Google Analytics, Fonts, and WordPress basics. You can copy this as a starting point, but remember to adapt it to your specific plugins/services:default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://stats.wp.com https://*.gravatar.com https://*.google.com https://*.gstatic.com https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https: *.gravatar.com; font-src 'self' https://fonts.gstatic.com data:; frame-src 'self' https://*.google.com https://*.bing.com; connect-src 'self' https://*.google.com https://public-api.wordpress.com; worker-src 'self' blob:;How to find what is missing (The Console Trick):
- Apply the policy above.
- Open your website in Chrome/Edge.
- Right-click anywhere and select Inspect.
- Go to the Console tab.
- Browse your site. If something is blocked (like a broken image or script), you will see a red error message: “Refused to load… because it violates the Content Security Policy directive…”
- Look at the domain in the error and add it to your policy string in the correct section (e.g., add https://facebook.com to script-src if a Facebook widget is blocked).
I hope this helps you build a strong policy without needing extra fields!
CSP (Content-Security-Policy) Example
Hi @zerocan,
Thank you for the suggestion!
Based on your screenshot, I see you are trying to add multiple CSP directives (like script-src, style-src, etc.) as separate Custom Headers.
The Solution:
You actually don’t need 10 separate fields for this. The Content-Security-Policy standard is designed to be sent as a single header containing all your rules separated by semicolons (;).How to do it correctly:
Instead of splitting them, combine your rules into one long string and put it in the main “Content Security Policy” field (if available) or in one single “Custom Header” field.Example:
- Header Name: Content-Security-Policy
- Header Value: default-src ‘self’; script-src ‘self’ https://example.com; style-src ‘self’ ‘unsafe-inline’; img-src ‘self’ data:;
This is the standard way browsers expect to receive the policy. Putting them all in one field is cleaner, more efficient, and follows the HTTP specification.
I hope this helps you configure it more easily!
Best regards,
Advanced IP Blocker Team
Forum: Plugins
In reply to: [Advanced IP Blocker] Bug Report: PHP Deprecated warning in PHP 8.1+Just a quick question:
Which PHP version are you currently running?We always test all releases before publishing them on the latest PHP versions (8.3 and 8.4), and we haven’t found any related entries in either the PHP error logs or the WordPress
WP_DEBUGlogs.Forum: Plugins
In reply to: [Advanced IP Blocker] Bug Report: PHP Deprecated warning in PHP 8.1+Hi @xemita,
Thanks again for the heads-up.
You are absolutely right: the issue is that WordPress is trying to process a page title that resolves to
nullthrough
strip_tags().
We traced this back to how our hidden “Setup Wizard” page was being registered. We were using an empty string
''as the parent slug, which in some environments causes WordPress to fail to retrieve the correct Page Title global, leading to that
nullvalue in the header.
We have updated the code to use
nullexplicitly for the parent slug, which is the strictly correct Standard for checking hidden pages in WordPress. This ensures the Page Title is correctly registered and retrieved, preventing the deprecated warning.
Status: This fix is committed and will be included in the upcoming release (8.8.1) scheduled for the next 24-48 hours. Since these are Deprecated warnings and not fatal errors, they shouldn’t affect the site’s functionality in production environments with
WP_DEBUGdisabled.
Best regards
Forum: Plugins
In reply to: [Advanced IP Blocker] Bypass API calls to avoid blocking themHi @niesan,
That is fantastic news! I am glad the “User-Agent Whitelist” solution worked smoothly for you. It is definitely the cleanest way to handle services like ShippyPro.
And thank you so much for your generous donation! It is support from users like you that allows us to keep this plugin free and constantly evolving without locking features behind a paywall. It truly means a lot to the development team.
If you have a spare moment, leaving a 5-star review would be amazing. It helps us grow and reach more people who need simple, powerful security.
👉 Rate Advanced IP Blocker here
If you ever need help with anything else, just let us know.
- This reply was modified 7 months, 1 week ago by IniLerm.
Forum: Plugins
In reply to: [Advanced IP Blocker] XMLRPC.php Still Being BlockedHi @thewatchman3,
Good news! We have just released version 8.8.0, which includes the fix for Application Passwords and XML-RPC compatibility.
Steps to fix your MarsEdit connection safely:
- Update the plugin to version 8.8.0.
- Re-enable 2FA for your user account (Security > Settings > Login & User Protection).
- Test MarsEdit: It should now connect perfectly using your Application Password without being intercepted by the 2FA screen.
Important Security Note:
If you added /xmlrpc.php to the “Global URL Exclusions” list as a temporary workaround, please remove it now. With this update, you don’t need that exclusion anymore, and removing it ensures your site stays fully protected against brute-force attacks on that endpoint.One more thing:
This update (v8.8.0) includes a major architectural upgrade for better performance and stability. After updating, we recommend clearing your browser cache (Ctrl+F5) and any server-side caches (like Redis/Object Cache) to ensure the new interface loads correctly.Let me know if everything works as expected!
Best regards,
Advanced IP Blocker Team
Forum: Plugins
In reply to: [Advanced IP Blocker] Bypass API calls to avoid blocking themHi @niesan,
Thank you for reaching out.
This is a very common scenario with external shipping services. Since they connect automatically using dynamic IPs, security plugins treat them as bots unless we explicitly tell the firewall they are trusted.
Here are two ways to solve this, from easiest to most robust.Plan A: Standard User-Agent Whitelist (Easiest)
- Go to Security > Blocking Rules.
- Click on the User Agents tab.
- Look for the box on the right side labeled “Whitelisted User-Agents List”.
- Add the following line (exactly as their support requested):
ShippyPro - Click Save User-Agent Lists.
Try connecting ShippyPro now. If it works, you are done!
Plan B: Advanced Rule (The “Nuclear” Option) <– Recommended
If Plan A doesn’t work (because some security layers like REST API protection might run before the standard whitelist check), use this method to force a total bypass for ShippyPro.
- Go to Security > Blocking Rules > Advanced Rules.
- Click + Add New Rule.
- Rule Name: ShippyPro Whitelist
- IF:
- Type: User-Agent
- Operator: Contains
- Value: ShippyPro
- THEN Action: Select Allow (Bypass Security).
- Click Save Rule.
This rule tells the firewall: “If the visitor identifies as ‘ShippyPro’, ignore all other security checks and let them in immediately.” This is the method recommended by their support team.
Let me know if this resolves the connection!
Best regards,
Advanced Ip Blocker Team
Forum: Plugins
In reply to: [Advanced IP Blocker] SSL “critical” with automatic DeepScanHello @wassi007,
1. Regarding the “Email only on error” option: Good news: This logic is already implemented as the default behavior in the current version. The automated background scan is designed to remain silent and NOT send any email if all checks pass (Status: Clean). The only reason you are receiving these emails right now is precisely because the scan is detecting the “SSL Critical” status. Once we solve that false positive, the daily emails will stop automatically and you will only hear from the plugin if a new issue arises.
2. Why SSL is still “Critical” (The Root Cause): Since version 8.7.5, our scanner explicitly checks your database setting (
get_site_url()). If it detects
https://there, it overrides the check and marks it as Safe.
If you are still seeing “Critical”, it implies that during the Cron execution, your WordPress is telling our plugin that its URL is
http://(not https).
This is extremely common in Plesk environments. Please check your
wp-config.phpfile. Do you have a line defining
WP_SITEURLor
WP_HOMEdynamically? Example:
define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/');The Fix: If you find such lines, change them to be hardcoded with HTTPS:
define('WP_SITEURL', 'https://your-domain.com/');This ensures that even when Cron runs from the command line (where server variables might be missing), WordPress knows it is an HTTPS site. This will instantly fix the SSL false positive and silence the daily reports.
Best regards, The Advanced IP Blocker Team