Metadata-Version: 2.4
Name: firemon-api
Version: 0.3.13
Summary: Python Wrapper for Firemon APIs
Author-email: Luke Johannsen <luke.johannsen@firemon.com>
License-Expression: MIT AND (Apache-2.0 OR BSD-2-Clause)
Project-URL: Documentation, https://firemon-api.readthedocs.io/en/latest/
Project-URL: Repository, https://github.com/lukejohannsen/firemon-api
Keywords: firemon,api,development
Classifier: Development Status :: 4 - Beta
Classifier: Intended Audience :: Developers
Classifier: Topic :: Software Development
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Requires-Python: >=3.10
Description-Content-Type: text/markdown
Requires-Dist: requests>=2.33.0
Requires-Dist: tenacity>=9.1

# FireMon-API

This project is for wrapper for the Firemon APIs (Security Manager, etc).

The User Guide available on [Read the Docs](https://firemon-api.readthedocs.io)

# Current Design

Everything is basically being coded by hand to a fit a schema that makes sense to me. Endpoints are made and return objects which may have their own functions. For example search and manipulation of devices and their data. This is an attempt to make the API a bit more user friendly without requiring more interaction by the user.

## Application Requests

The user may use the `/api-doc` from your FireMon server to extrapolate the need keys and methods to make and use the `request()` function for the specific FireMon application. This method is handy to test out what will be returned. This is handy for testing out functions and seeing results before coding up code that tries and fit the rhyme scheme for this module or get results that may yet not be coded.

```
>>> fm.sm.request(key="device", use_domain=True).get()
[{'id': 27, 'domainId': 1, 'name': 'PA-VM 11.0.1', 'managementIp': <snip...>]
```

## Dynamic API

I have attempted to create a dynamic interface for all API calls if there is something needed that does not currently fit within the re-imagining of the API schema for user friendliness. Each application should automatically create these. Unfortunately many of the `operationId` for the API are not helpful in what they actually do:

ex: (`get_1`, `get_2`, `get_3`, ...)

Probably best to avoid this unless you are a sadist.

# Usage

Import module. Disable unverfied https certificate warnings. Switch https verification off.

```
>>> import firemon_api as fmapi
>>> fmapi.disable_warnings()
>>> fm = fmapi.api('saffron', verify=False).auth('firemon', 'firemon')
>>> fm
<Firemon(url='https://saffron', version='10.0.0')>
>>> for dev in fm.sm.devices.all():
...   print(dev.name)
...
asa-2961.lab.firemon.com
ASA5505-8-3-2
ciscoASA8dot2
CSM-2
vSRX-3
```

Create a new Device. Newer versions of Firemon require we specify which Collector Group and ID to use. Grab the first Collector Group. 

Use all the default information from the device pack for our device.

Add in some required information and other settings to our dictionary.

Create the device.

```
>>> cg = fm.sm.collectorgroups.all()[0]
>>> config = fm.sm.dp.get('juniper_srx').template()
>>> config['name'] = 'Conan'
>>> config['description'] = 'A test of the API'
>>> config['managementIp'] = '10.2.2.2'
>>> config['collectorGroupId'] = cg.id
>>> config['collectorGroupName'] = cg.name
>>> config['extendedSettingsJson']['password'] = 'abc12345'
>>> dev = fm.sm.devices.create(config)
>>> dev
<Device(Conan)>
```
