Calling addPolicy Safely: Batch in Tens, Then Verify the Grant

#camera #automation

Call addPolicy from a trusted backend with an administrator accessToken, the sub-account openid, and a Policy that uses only documented permission names and dev: / cam: resources. Split large fleets so each request stays within the live limit: a maximum of 10 devices or channels per call, and statement or resource arrays no longer than 10 on the current page. Then query the granted policy instead of trusting the HTTP transport alone.

Why it matters

A provisioning job that posts the entire site as one Policy will fail as soon as the tenth resource is exceeded. A job that retries by widening device-level Real grants can overshare channels. Safe code is a chunker plus a verifier, not a bigger JSON body.

This article is about the caller loop. Inheritance details belong on the sub-account and addPolicy pages; re-read them when you choose dev: versus cam:.

Approach / architecture

desired grants {openid, permission, resource}
  -> validate names against documented vocabulary
  -> chunk to <= 10 resources per addPolicy
  -> administrator addPolicy
  -> query policy / permission
  -> product ledger

Documented permission names include Alarm, Config, Ptz, Capture, Upgrade, Format, Real, RecordReplay, Talk, and DevControl. Do not invent aliases.

Six implementation steps

Build the desired-grant list in your product model first. Tenant, user, device, channel, and operation must already be authorized in your app.
Normalize resources. Use the live resource syntax. Prefer channel resources when the user should not receive every child channel of a device.
Chunk. Conservative builders cap each request at 10 total resource references and 10-length arrays, matching the current addPolicy page. Recheck that number before production.
Send sequential or limited-parallel calls. Respect your own rate limits. Use a new signed envelope per HTTP attempt.
Verify. Use the documented permission-query interfaces after each chunk. Store the Imou openid and resource list in your ledger.
Offboard with the matching write APIs. Clearing or deleting policy is as important as add. Do not leave grants when the product user is removed.

APIs / SDKs

addPolicy
Sub-account description
Related policy/query/delete methods on the account module pages

Limits & pitfalls

Do not interpret “10” as 10 statements times 10 resources unless the live page says so; stay conservative.
Device-level grants can inherit to child channels; that is a scope decision, not a batching trick.
Administrator token stays on the backend.
Recheck the limit and permission vocabulary on publication day.

Failure handling and audits

If addPolicy fails on chunk 4 of 12, persist which resources succeeded. A naive retry of the entire list can duplicate grants or hit the 10-resource limit again for a different reason. Store per-chunk request id and platform result codes.

Audit logs should show actor (your operator or system), target openid, permission names, resource list, and chunk index—not the administrator token. Security review should sample policies for unexpected DevControl or device-level Real on users who should only preview one channel.

When inheritance is used, add a test: grant Real on dev:X and confirm the product UX does not accidentally expose a second channel you did not intend to sell. If it does, switch the grant to cam: resources even if that means more chunks.

Do not build a “sync all permissions from our RBAC in one request.” Chunking is mandatory under the current contract. Parallelism should be bounded; a fan-out of hundreds of addPolicy calls can create its own quota and lock problems in your workers.

Re-read addPolicy whenever you upgrade the integration. Limits and array names can be documented with examples; your validator should follow the live page, not this article’s memory of “10.”

Chunk grants against the live addPolicy contract, then verify from your backend before you mark a user as provisioned on Imou Open Platform.

DEV Community