stamler / charade Goto Github PK

JSON Patch (RFC 6902) supports 6 operations: add, remove, replace, move, copy, and test. Currently only replace is defined. add and replace should reflect adding objects to related tables rather than the primary table since by implication they are adding or removing properties that don't exist as columns in the primary table. Otherwise we would simply be doing a replace, even to set an unset value for the first time.

the HTTP PATCH method against an individual resource object will map to an UPDATE statement in SQLAlchemy. The format will likely be JSON Patch. This will complete CRUD functionality as POST, GET, PATCH, DELETE HTTP verbs for every resource. Some resources will return 405 Method Not Allowed, of course.

Leverage SQL Alchemy for versioned joins with history. Some examples are here. This is the most terse example. Some further potentially useful background is here.

After considering this problem, the basic implementation should centre around having the current value of a property being stored in the row of the table. Previous value(s) would be stored in a separate table with a datetime stamp indicating when that record was created. Rows would be added to the history table every time a row is edited in the primary table. There would be one history table per property.

There is a private model.py file which provides a schema and functionality to charade. If this file is not available then charade will reflect the entire database and is supposed to operate normally. Unfortunately the custom model.py creates table names that don't match the reflected class names if reflection is used, breaking auth.

The best approach to fix this is to break authorization out into a submodule that always uses the same table names and model.py then import this into charade as middleware.

The interim solution is to hard-code the auth schema and tables into database.py then reflect any other data tables into the app for export as a JSON API. This is a useful intermediate step to breaking out the authorization system as well.

Build functionality inside the Docker image to simply acquire a Let's Encrypt certificate for rapid deployment.

When a table exists that stores history of a property on a primary table, this is a 1-to-N relationship. The behaviour should be such that a GET request to, for example, /Computers/{id}/LocationsHistory should return a list of objects with historical locations and datetimes of creation.

No unit tests or integration tests have been created for charade. Cannot release without creating a solid test suite, verifying coverage, verifying passing.

Separate tests for the AzureADTokenValidator could be useful as well, although this middleware would ideally be broken out into a separate project / importable module

Databases have foreign keys which define 1-to-N relationships. GET requests to endpoints such as /SoftwareTitles/{id}/SoftwareKeys should return a list of SoftwareKeys objects that belong to the specified SoftwareTitles object. These could be cached in client to reduce requests as well.

Lots of work happening outside of docker but deployment is crucial. Ensure deployment from docker works with environment variables.

Some sort of RBAC needs to be implemented against the existing AzureAD system. If Azure resource tokens can include security group information (it can) then the actual configuration can happen in the on-premises AD instance. The charade database stores a list of tasks (id, HTTP verb, Resource) and permissions (id, task_id, group). A hook in the router will check group id of the supplied token and compare it to the requested resource. If it's not allowed, the system will return an HTTP error, possibly stating the required permissions?

All necessary configuration for an instance should be inside model.py except for possibly the AzureAD stuff (tenant/app etc). This should include complete validation of object properties.

5f467bb introduces an issue where multiple of debug log entries (from __init__ Database and onward) are in duplicate. Either logging is running in duplicate or there are two copies of the running process.

Ensure all responses (including errors) conform to JSON API. Also ensure that requests that do not confirm to JSON API are replied to with an error message.

The falcon documentation discusses a JSON Schema validator that may be useful.