A city location HTTPS receiver accepts Meraki Scanning POSTs. Besides TLS, what authenticates that the JSON came from that Meraki network?
Select an answer to reveal the explanation.
Short Explanation
TLS encrypts the truck; the shared secret proves which Meraki network loaded it. Reject POSTs whose secret does not match what you set in Dashboard.
Full Explanation
Besides TLS encryption in transit, Meraki Scanning authenticity for a city location receiver relies on a shared secret configured in Dashboard and carried in the JSON body of each POST. The consumer must compare that secret to the expected value for the network and reject mismatches so arbitrary Internet clients cannot inject fake observations into civic analytics.
Trusting any TLS client because certificate issuance somehow “proves Meraki” fails: TLS protects the channel to your receiver; it does not by itself prove the POST was generated for your Meraki network. Requiring an FDM Bearer access_token on Scanning POSTs fails platform mixing—FDM tokens are unrelated to Meraki location push auth. Accepting posts only when User-Agent contains “Cisco” fails security design: User-Agent strings are trivial to spoof and are not the shared-secret control.
Exam caveat: treat the scanning secret like an API key—store it hashed or in a secret manager, rotate on leak, and never log full raw bodies in shared municipal debug channels.
Operational check: send a synthetic POST with the wrong secret and confirm 401/403 or drop behavior; send one with the correct secret and confirm acceptance and parse.