A coffee chain hosts its own signup page on a company web server and points the guest SSID's splash setting to that external URL. Customers reach the form, but nobody gets online. In the Meraki external captive portal flow, which step must the hosted page perform after the customer submits the form to authorize the client?
Select an answer to reveal the explanation.
Short Explanation
Your page has exactly one job here, and it can't skip it: load the grant URL supplied in the redirect. That tells the access point to admit the client, like returning the numbered ticket the door clerk handed you at the entrance.
Full Explanation
When an SSID uses an external captive portal, the access point redirects the customer's browser to the splash URL registered in Dashboard, appending parameters such as the grant URL and the client MAC address. The session becomes authorized only when your page loads the supplied grant URL through the browser, which tells the access point the client may pass; the success or landing page then appears as a courtesy redirect. Redirecting straight to the success page changes nothing by itself, because the access point never receives an authorization decision from it. Posting credentials to a portal login endpoint belongs to a splash-with-RADIUS flow, where credentials are validated through RADIUS, so that exchange is not the authorization step in this scenario. Firing a webhook sends an event to subscribed listeners for alerting, which is unrelated to releasing a client on the wireless side. Practical check: open browser developer tools, follow the redirect chain, and confirm your page loads the grant URL.