Hi,
I'm trying to understand whether the following behavior is expected or if there is a permission inconsistency between the Meraki Dashboard UI and Dashboard API.
We have an administrator with Read-only access at the Network level.
From the Meraki Dashboard UI, this administrator is able to perform a port cycle / bounce on a switch port.
However, using an API key belonging to the same administrator, the following endpoint returns 403 Forbidden:
POST /devices/{serial}/liveTools/ports/cycleI then checked what the Dashboard UI does using the browser DevTools.
Interestingly, when the same Read-only administrator cycles port 17 on switch from the Dashboard, the UI does not appear to use the public REST endpoint. Instead, it sends a request through the Dashboard's internal CometD connection:
POST https://<dashboard-shard>.dashboard.meraki.com/cometd/
The relevant CometD request contains:
{
"channel": "/requests",
"data": {
"node_id": "<node_id>",
"ports": "17",
"module_ports_info": [],
"type": "PortBouncing"
}
}The Dashboard first subscribes to:
/node/<node_id>/PortBouncing
and the /requests message is accepted with:
{
"channel": "/requests",
"successful": true
}It then unsubscribes from the PortBouncing channel.
The port cycle itself works successfully from the Dashboard with this Read-only account.
So there appear to be two different authorization paths:
Dashboard UI + Read-only admin
-> internal CometD "PortBouncing"
-> allowed
Dashboard API + same Read-only admin
-> POST /devices/{serial}/liveTools/ports/cycle
-> 403The API behavior itself makes sense since triggering a port cycle is treated as a write operation. What I find interesting is that the Dashboard UI intentionally allows what is effectively the same operational action to a Read-only administrator.
Is this difference excepted ? Or is this simply a permission mismatch between the Dashboard UI and Dashboard API ?
Thanks for any insighe, if someone already observed this mismatch...
Regards
