Nms-existing-tests

Links to different tools

Local LAN links to different monitoring tests

1. http://192.168.15.249/event?sort=eventSeverity&direction=DESC
2. http://backup01:85/windowDetail.php?id=5d1036d709297
3. http://backup01:85/wob2.php
4. http://webserver01:82/event/tables/event.html
5. http://larvel01:8002/events/stateChange/after/2021-10-11%2008:25:57
6. https://observium.iwillfearnoevil.com/device/device=47/tab=ports/

Testing to be written

Testing and Unit tests for nmsApi will have to be documented here.

• In theory the validator in the api will catch most oddball errs.
• practical is run through 100% invalid "things" and 100% valid "things" and then mix
• mock the database?
• Test Database in parallel with main database?
• add automation into gitlab runner with a remote db for testing? Reasonable..
• build db, insert all defaults from a dump then test
• build a db with a large amount of 100% valid fake (but valid) data that we can hammer against

Areas for discrete tests

• authentication local
• authentication TFA
• authentication LDAP
• API each route
• Each discrete Graphing option
• poller inputs
• templates

Need to think of a good solution to this

The frontend is going to have to be addressed all on its own. In general the backend should NOT trust the frontend at all. Frontend should be able to be swapped out without anything on the backend caring other than the authentication validation. The frontend ITSELF will have to validate against the backend as well as user authentication. It is not a good idea for random un-authenticated apps or shims to be able to talk to all the APIs without some kind of validation happening. While user auth is a good start, TBH we cannot say that we can trust the frontend or something that SAYS it is the frontend without checking. The frontend on setup with the backend will have to "register" itself as a known acceptable frontend service of some kind.

Overall certain routes will never need auth, as they are adhoc ingress points such as snmptrap and event/create API. Anything that goes into these ingress points must be validated to not contain executable code and will never execute a process unexpectedly. There will be times such as a mapped event triggering something to happen when they go live, however the trigger is isolated from the incoming event itself. Some thought will have to be given to new ingress points such as collectd or other ones that an end user may wish to use. We are going to need a good way to ingest these new inbound routes with safeties in place so that they cannot damage the system. Likely a shim of some kind will have to be implemented for things such as collectd to translate into API calls which are sanitized.