Many of the functions utilise the __hasorgaccess function in order to test access prior to proceeding.
This sounds fine, however currently it appears that the /api/v0/organizations call will fail if one of the organizations which an API key's owner has access to is employing "IP address whitelisting" (Organization -> Settings -> Security -> Login IP Ranges), and the requestor's IP address is not included in the configured ranges.
E.g.
- User has 2 organizations which they are a member of
- OrgA has "whitelisting" configured, allowing only
1.2.3.4
- OrgB does not have "whitelisting" configured
- User attempts to call
/api/v0/organizations from 5.6.7.8 to find out which orgs they have access to - response:
403 - You are trying to access Dashboard from an unauthorized IP address (5.6.7.8). Contact your network administrator for more information.
Because of this error, __hasorgaccess will fail, whether the org involved is using "whitelisting" or not, and then the original call will also fail.
E.g.
----> 1 meraki.getnetworklist(api,org)
~/meraki/meraki.py in getnetworklist(apikey, orgid, templateid, suppressprint)
1775 # Confirm API Key has Admin Access Otherwise Raise Error
1776 #
-> 1777 __hasorgaccess(apikey, orgid)
1778 calltype = 'Network'
1779
~/meraki/meraki.py in __hasorgaccess(apikey, targetorg)
806 if validjson is True:
807 for org in currentorgs:
--> 808 if int(org['id']) == int(targetorg):
809 orgs.append(org['id'])
810 return None
TypeError: string indices must be integers
I believe the API endpoint /api/v0/organizations is not behaving as expected.
I would expect that it should either:
- provide a list of organizations which the API key is allowed to access from the current IP (excluding OrgA in the above case), or
- provide a list of organizations which the API key's owner is an administrator of (regardless of IP restrictions), and return an error when attempting to access an organization (using any call which would provide information about, or modify the target organization) which has excluded the requestor's IP address.
Regardless, it's current behaviour is breaking this module is operating if any org that the user is a member of is employing "whitelisting".
If this is the correct behaviour of /api/v0/organizations, perhaps this module can be modified to use another call to test access to an org.
I'm going to "make a wish" containing the following content, in order to try and get /api/v0/organizations fixed:
# Fix `/api/v0/organizations` API endpoint
It appears that the `/api/v0/organizations` call will fail if one of the organizations which an API key's owner has access to is employing "IP address whitelisting" (Organization -> Settings -> Security -> Login IP Ranges), and the requestor's IP address is not included in the configured ranges.
E.g.
* User has 2 organizations which they are a member of
* OrgA
* OrgB
* OrgA has "whitelisting" configured, allowing only `1.2.3.4`
* OrgB does not have "whitelisting" configured
* User attempts to call `/api/v0/organizations` from `5.6.7.8` to find out which orgs they have access to - response:
> 403 - You are trying to access Dashboard from an unauthorized IP address (5.6.7.8). Contact your network administrator for more information.
I believe the API endpoint `/api/v0/organizations` is not behaving as expected.
I would expect that it should either:
* provide a list of organizations which the API key is allowed to access from the current IP (excluding OrgA in the above case), or
* provide a list of organizations which the API key's owner is an administrator of (regardless of IP restrictions), and return an error when attempting to access an organization (using any call which would provide information about, or modify the target organization) which has excluded the requestor's IP address.
This also affects the meraki.py python module's operation, due to the way it relies on `/api/v0/organizations` - more information here: https://github.com/meraki/dashboard-api-python/issues/28
Please modify `/api/v0/organizations` so that it operates more in line with user expectation (as one of the above expectations, if possible).
Thank you!
🙂
Many of the functions utilise the
__hasorgaccessfunction in order to test access prior to proceeding.This sounds fine, however currently it appears that the
/api/v0/organizationscall will fail if one of the organizations which an API key's owner has access to is employing "IP address whitelisting" (Organization -> Settings -> Security -> Login IP Ranges), and the requestor's IP address is not included in the configured ranges.E.g.
1.2.3.4/api/v0/organizationsfrom5.6.7.8to find out which orgs they have access to - response:Because of this error,
__hasorgaccesswill fail, whether the org involved is using "whitelisting" or not, and then the original call will also fail.E.g.
I believe the API endpoint
/api/v0/organizationsis not behaving as expected.I would expect that it should either:
Regardless, it's current behaviour is breaking this module is operating if any org that the user is a member of is employing "whitelisting".
If this is the correct behaviour of
/api/v0/organizations, perhaps this module can be modified to use another call to test access to an org.I'm going to "make a wish" containing the following content, in order to try and get
/api/v0/organizationsfixed:Thank you!
🙂