cancel
Showing results for 
Search instead for 
Did you mean: 

Automatic provisioning flow broken

Automatic provisioning flow broken

We are currently working on an application that automatically supplies meraki devices (from the configuration of organizations, networks, devices, SSIDs, to serving the "splash page" in the Access Point, one different per SSID of a Network, 15 in total). 
 
We have detailed knowledge of the following APIs:
 
 
 
 
We can't achieve a complete provisioning flow since there is no "request" in the APIs that configure a custom splash URL. This can be manually done in the Meraki portal.
 
For a high number of requests, making that configuration manually would be very impractical, we need detailed information about how you have implemented this functionality in the Meraki portal "https://n174.meraki.com/"
1 REPLY
Meraki Employee

Re: Automatic provisioning flow broken

Hi,

I agree that an API to assign the splash url would be ideal, that's not the case today.

 

That being said, the way I've accomplished this is by using the access points MAC address. This only works if you have one splash page per network, which is the most common scenario.

 

I use a custom JS library I'm writing to handle these types of use cases:

https://dexterlabora.github.io/meraki-service/module-Custom.html#.getNetworkIdForDeviceMac

 

 

meraki.getNetworkIdForDeviceMac(orgId, deviceMac)
    .then(response => {
      console.log(response);
}

// Network ID
// L_123456789012345

With the network ID, lookup the name/details, then apply custom policies to the client or deliver location specific content.

 

 

btw, are you really serving 15 SSIDs on the same AP? This is not a best practice if so. I would consider dynamic splash pages on a single SSID, where possible. Unique SSIDs should only be advertised when they require different association types (open/WPA2/Ent). This will reduce interference by lowering broadcasts, etc.