Tencent/APIJSON · error · IllegalAccessException

{} 不允许 {} 用户的 {} 请求!

Error message

{} 不允许 {} 用户的 {} 请求!

What it means

In verifyRole(), when the target table is registered in SYSTEM_ACCESS_MAP and Log.DEBUG is false, any request from a non-privileged path is refused with IllegalAccessException. SYSTEM_ACCESS_MAP lists tables reserved for the framework itself (such as access/system configuration tables); in production mode (DEBUG off) they are unreachable through the normal API. This is a deliberate hard block, not a role-mapping problem.

Source

Thrown at APIJSONORM/src/main/java/apijson/orm/AbstractVerifier.java:322

	 * @throws Exception
	 * @see {@link JSONMap#KEY_ROLE}
	 */
	public void verifyAllowRole(SQLConfig<T, M, L> config, String table, RequestMethod method, String role) throws Exception {
		Log.d(TAG, "verifyAllowRole  table = " + table + "; method = " + method + "; role = " + role);
		if (table == null) {
			table = config == null ? null : config.getTable();
		}

		if (table != null) {
			if (method == null) {
				method = config == null ? GET : config.getMethod();
			}
			if (role == null) {
				role = config == null ? UNKNOWN : config.getRole();
			}

			if (Log.DEBUG == false && SYSTEM_ACCESS_MAP.get(table) != null) {
				throw new IllegalAccessException(table + " 不允许 " + role + " 用户的 " + method.name() + " 请求!");
			}

			Map<RequestMethod, String[]> map = ACCESS_MAP.get(table);

			if (map == null || Arrays.asList(map.get(method)).contains(role) == false) {
				throw new IllegalAccessException(table + " 不允许 " + role + " 用户的 " + method.name() + " 请求!");
			}
		}
	}

	/**校验请求使用的角色,角色不好判断,让访问者发过来角色名,OWNER,CONTACT,ADMIN等
	 * @param config
	 * @param table
	 * @param method
	 * @param role
	 * @return
	 * @throws Exception
	 * @see {@link JSONMap#KEY_ROLE}

View on GitHub (pinned to 5284052872)

Solutions

  1. Stop querying the system/reserved table from client requests — expose the data through a dedicated controller or a copy of the data in a normal table.
  2. If this is an administration tool run in a trusted debug deployment, set Log.DEBUG = true (development only; never in production).
  3. Re-check that the table name in the request is actually the business table you meant — a typo can resolve to a system table name pattern.

Example fix

// before (production, Log.DEBUG == false)
{ "Request": { } }  // Request is a system table -> blocked

// after
// Query a normal business table, or read system data via a custom controller
{ "MyAppConfig": { "id": 1 } }
Defensive patterns

Strategy: validation

Validate before calling

// client/server pre-check: never route system tables through the public API
if (Log.DEBUG == false && SYSTEM_ACCESS_MAP.containsKey(tableName)) {
    reject("table " + tableName + " is a system table and not accessible in production");
}

Type guard

boolean isSystemTable(String t) { return AbstractVerifier.SYSTEM_ACCESS_MAP.containsKey(t); }

Try / catch

catch (IllegalAccessException e) { respond 403; log the blocked table+role+method for audit; never retry with different roles to probe.

Prevention

When it happens

Trigger: A client sends a GET/POST/PUT/DELETE against a table that exists in SYSTEM_ACCESS_MAP (framework system table) while Log.DEBUG == false; the first branch in verifyRole throws regardless of the role sent.

Common situations: Running the same requests that worked in local DEBUG mode against a production deployment where Log.DEBUG=false; probing framework tables (e.g. '_access' style config tables) through the public API; forgetting that system tables are only accessible in debug builds.

Related errors


AI-assisted analysis of Tencent/APIJSON@5284052872 (2026-08-14). Data as JSON: /api/errors/546ecc760892071e. Report an issue: GitHub.