Suspect that the RateLimiter class is breaking the block editor for Editor roles

(@helgatheviking)

An Editor on my site is running into a lot of 429 too many requests errors in the block editor when trying to add/edit a post.

I think that is might be related to the Ninja Forms RateLimiter class which seems to apply to any logged in user who is NOT an admin (as checked by the

if ( is_user_logged_in() && current_user_can( 'manage_options' ) ) {

I think only admins have manage_options capabilities right? So this would impact non-editors in the admin area? For now I have a snippet to increase the limit for my user, but shouldn’t this be limited to the frontend only?

namespace NinjaForms\Blocks\Authentication;

/**
 * Rate limiter for Views REST API endpoints.
 *
 * Prevents DoS attacks by limiting requests per IP address.
 */
class RateLimiter {

    /** @var int Default rate limit (requests per window) */
    const DEFAULT_LIMIT = 60;

    /** @var int Default time window in seconds */
    const DEFAULT_WINDOW = 60; // 1 minute

    /** @var string Transient key prefix */
    const TRANSIENT_PREFIX = 'nf_views_rate_limit_';

    /**
     * Check if the current request should be rate limited.
     *
     * @param string $endpoint Endpoint identifier (e.g., 'submissions', 'forms')
     * @param int    $limit    Maximum requests per window (default 60)
     * @param int    $window   Time window in seconds (default 60)
     *
     * @return bool|\WP_Error True if allowed, WP_Error if rate limited
     */
    public static function check( $endpoint, $limit = null, $window = null ) {
        // Allow disabling rate limiting via constant
        if ( defined( 'NF_VIEWS_DISABLE_RATE_LIMITING' ) && NF_VIEWS_DISABLE_RATE_LIMITING ) {
            return true;
        }

        // Allow disabling for logged-in admins
        if ( is_user_logged_in() && current_user_can( 'manage_options' ) ) {
            return true;
        }

// truncated

Viewing 2 replies - 1 through 2 (of 2 total)

Faisal Ahammad
(@faisalahammad)

1 week, 4 days ago
Hi @helgatheviking,

I reviewed the behavior and the issue does look related to how the Ninja Forms Views rate limiter handles logged-in users in the block editor.

At the moment, the plugin appears to apply its Views API rate limiting to non-admin users even when they already have permission to access submissions. On some sites, that can cause 429 Too Many Requests errors in the block editor for Editor users or other non-admin roles. A temporary workaround is to raise the rate limit only for logged-in users who already have the same Ninja Forms submissions/view capability configured on the site.

If you want to try that, you can add the following as a small MU plugin:
```
<?php
/**
 * Plugin Name: Ninja Forms Views Rate Limit Workaround
 * Description: Prevents authorized non-admin users from hitting Ninja Forms Views rate limits in the block editor.
 */

defined( 'ABSPATH' ) || exit;

add_filter( 'ninja_forms_views_rate_limit', function( $limit, $endpoint ) {
    if ( ! is_user_logged_in() ) {
        return $limit;
    }

    $views_capability = apply_filters(
        'ninja_forms_views_token_capability',
        apply_filters( 'ninja_forms_admin_submissions_capabilities', 'manage_options' )
    );

    if ( current_user_can( $views_capability ) ) {
        return 1000;
    }

    return $limit;
}, 10, 2 );
```
You can install it like this:
1. Create this file:
  /wp-content/mu-plugins/nf-views-rate-limit-workaround.php
2. Paste the code above into that file.
3. If the mu-plugins folder does not already exist, create it first.
4. Save the file and test again with the affected Editor user.
This workaround does not disable rate limiting for everyone. It only increases the limit for logged-in users who already have permission to access the Ninja Forms Views/submissions endpoints, so public or unauthorized traffic will still use the normal rate limit.

Just to set expectations clearly, I am not part of the Ninja Forms team. I am helping here as a volunteer. Because of that, if this custom code does not work in your specific setup, the official Ninja Forms support team may not be able to troubleshoot or support it, since custom snippets are usually outside their support scope.

That said, based on the code path involved, this looks like a reasonable and low-risk workaround until the plugin itself is updated.

Best regards,
Faisal (volunteer)
Thread Starter HelgaTheViking
(@helgatheviking)

1 week, 3 days ago

Thanks Faisal! I will test that out.

Viewing 2 replies - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.