Skip to content

__hasorgaccess problematic when organization employs whitelisting #28

Description

@xorcat

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
    • 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.

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!
🙂

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions