Napp is an abbreviation of ‘Nano App’ which is a term I am using to describe a web application
that has a very small footprint. Specifically, Napp bootstraps a new application for you by
creating a project, necessary files and connects them all up so you can dive straight into
building your application.

• About
• Prerequisites
• Installation
• Usage
• Deployment
• Contributing
• Contributors
• License

What is a Nano App?
The rules are simple, a nano app must have as few files as possible, as few directories as possible,
little to no JavaScript (minus HTMX), has a small Docker image (size does matter) and must be easy
to develop and deploy.

If you want to take a look at how a Nano App is structured by napp, please vist Napp Generated

Below are some potential use cases for a Nano App.

UI/UX Experimentation – Use HTMX’s dynamic capabilities to experiment with different user events.

Proof of Concepts – Create a lightweight app to showcase the feasibility of a technical concept.

Admin Interfaces – Develop basic admin panels to manage users, or config settings for internal systems.

Go Practice – Use Napp as a framework to build small projects and improve your Go and web skills.

HTMX Exploration – Explore the power of HTMX for building reactive interfaces with minimal JavaScript.

• Go (this project is built with 1.24) but it should work with older versions too.
• Make sure your Go bin is added to your path so that installed packages can be used globally.

go install github.com/damiensedgwick/napp@latest

You can download the compiled binary for your machine from Releases.
Once you have done this, make sure the executable has the correct permissions and make sure it is in your path.

napp init <project-name>

cd <project-name>

go mod init <your-chosen-path>

go mod tidy

Display the Napp help menu to get a list of currently available commands.

napp --help

Get the current version with the following command:

napp --version

Go has everything you need to build and run the application locally and it is
usually the default choice when wanting to develop and iterate quickly.

go run cmd/main.go

Docker has been setup is so that the binary is prebuilt using Go and then it is simply
copied into the Docker image, resulting in a smaller footprint the final Docker image.

NB The Dockerfile is currently setup to build for Linux, if your OS is not Linux
you will need to change it accordingly.

docker build -t app-name .

docker run -d -p 8080:8080 app-name

At the moment I recommend using Fly.io for deploying Nano Apps. They provide a great
command line tool to make managing the process easy and you can have 3 x small projects
on there each with a 1gb persisted SQLite database volume for prototyping.

You will need to make sure you have the Fly.io command line tools installed for the
following steps. If you do not have them installed, you can find out how to install them
here: flyctl command line tool

Once you have installed the above command line tools and signed in to Fly.io, you are
ready to proceed with the next steps, each step is supposed to be run from your project
root.

1. Get your app ready for deploying: fly launch --no-deploy

The command line will prompt you to check if you would like to change the default
configuration. It is important to say yes so that you can select your region and
lower the apps memory to 256mb vs the default settings.

2. Copy the following into your fly.toml

[[mounts]]
  source = "godo_database"
  destination = "/data"
  initial_size = "1gb"

3. Deploy your application fly deploy

This command should now deploy your application to Fly.io and create the
necessary resources (such as our volume) in the process.

4. List Machines to check attached volumes: fly machine list

# expected output
my-app-name
ID              NAME        STATE   REGION   IMAGE                  IP ADDRESS                      VOLUME                  CREATED                 LAST UPDATED            APP PLATFORM    PROCESS GROUP   SIZE
328773d3c47d85  my-app-name stopped yul     flyio/myimageex:latest  fdaa:2:45b:a7b:19c:bbd4:95bb:2  vol_6vjywx86ym8mq3xv    2023-08-20T23:09:24Z    2023-08-20T23:16:15Z    v2              app             shared-cpu-1x:256MB

5. List volumes to check attached Machines: fly volumes list

# expected output
ID                      STATE   NAME    SIZE    REGION  ZONE    ENCRYPTED       ATTACHED VM     CREATED AT
vol_zmjnv8m81p5rywgx    created data    1GB     lhr     b6a7    true            5683606c41098e  3 minutes ago

6. Add your environment variables to Fly.io

You will need to add the following variables to your app in the Fly.io dashboard.
First navigate to your machine and then to secrets.

Add the following 2 secrets:

APPNAME_NAME_COOKIE_STORE_SECRET="value" or APP_NAME_NAME_COOKIE_STORE_SECRET="value"

and

APPNAME_NAME_DB_PATH="value" or APP_NAME_DB_PATH="value"

NB Check your generated .env file to see how your app name should be
written and add your database path value and your cookie store secret value.

Once these have both been added, we should be ready to deploy for the last time!

6. Run the following command to deploy your app and make use of your .env variables

fly deploy

🎉 That should be all you need to do to get your nano app deployed on Fly.io with persisted storage. 🎉

I’d love to have your help making Napp even better! Here’s how to get involved:

• Fork the repository. This creates your own copy where you can work on changes.
• Create a separate branch for your changes. This helps keep your work organised.
• Open a pull request with a clear description of your contributions.

A huge shoutout to the following for contributing towards Napp and making it all that
little bit better!

• Dmytro Borshcanenko

The MIT License (MIT)

Copyright (c) Adam Veldhousen

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the “Software”), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

Paste middleware to produce a CADF audit trail from OpenStack API calls. Currently the following OpenStack services are supported out-of-the-box today:

• Nova
• Neutron
• Cinder
• Designate
• Manila
• Glance
• Barbican
• Ironic
• Octavia

Additional APIs can be supported without major code changes through templates.

It is a major redesign of the original audit module within the keystonemiddleware. It has been invented to produce a more verbose audit trail that can be consumed by auditors, end users and complex event processing infrastructures alike.

For that reason it does not adhere to the existing OpenStack taxonomy for CADF. The biggest difference is that it populates the target part of the CADF event with the actual resource/object affected by the action. This is a prerequisite to user friendly presentation of events, e.g. navigation from event to target objects. Previously, the essential information which target object has been affected by an audit-relevant action had been buried in the requestPath attribute or was not available at all.

For operators the difference is minor though. The integration of the new middleware in the OpenStack service works the same way with the only change being different mapping files and of course the new binaries.

The figure above shows the middleware in Nova’s pipeline.

To enable auditing, oslo.messaging should be installed. If not, the middleware will write audit events to the application log instead.

Auditing is enabled by editing the services’s api-paste.ini file to include the following filter definition:

[filter:audit]
paste.filter_factory = auditmiddleware:filter_factory
audit_map_file = /etc/nova/api_audit_map.yaml

The filter must be included after Keystone middleware’s authtoken filter so it can utilise request header variables set by it.

Below is an example using Nova’s WSGI pipeline::

[composite:openstack_compute_api_v2]
use = call:nova.api.auth:pipeline_factory
noauth = faultwrap sizelimit noauth ratelimit osapi_compute_app_v2
keystone = faultwrap sizelimit authtoken keystonecontext ratelimit audit osapi_compute_app_v2
keystone_nolimit = faultwrap sizelimit authtoken keystonecontext audit osapi_compute_app_v2

To properly audit api requests, the audit middleware requires a mapping file. The mapping files describes how to generate CADF events out of REST API calls.

The location of the mapping file should be specified explicitly by adding the path to the audit_map_file option of the filter definition::

[filter:audit]
paste.filter_factory = auditmiddleware:filter_factory
audit_map_file = /etc/nova/api_audit_map.yaml

For each supported OpenStack services, a mapping file named <service>_api_audit_map.yaml is included in the etc folder of this repo.

Additional options can be set:

Certain types of HTTP requests can be ignored entirely. Typically GET and HEAD requests should not cause the creation of an audit events due to sheer volume.

# ignore any GET or HEAD requests
ignore_req_list = GET, HEAD

The payload of the API response to a CRUD request can be attached to the event optionally. This will increase the size of the events, but brings a lot of value when it comes to diagnostics. Sensitive information can be filtered out using the payloads attribute of the resource mapping specification (see below).

# turn on logging on request payloads
record_payloads = True

Audit middleware can be configured to use its own exclusive notification driver and topic(s) value. This can be useful when the service is already using oslo messaging notifications and wants to use a different driver for auditing e.g. service has existing notifications sent to queue via ‘messagingv2’ and wants to send audit notifications to a log file via ‘log’ driver.

The oslo messaging configuration for the audit middleware is at the same place as service’s oslo messaging configuration: the service configuration file (e.g. neutron.conf)

Example shown below:

[audit_middleware_notifications]
driver = log

When audit events are sent via ‘messagingv2’ or ‘messaging’, middleware can specify a transport URL if its transport URL needs to be different from the service’s own messaging transport setting. Other Transport related settings are read from oslo messaging sections defined in service configuration e.g. ‘oslo_messaging_rabbit’.

Example shown below:

[audit_middleware_notifications]
driver = messagingv2
transport_url = rabbit://user2:passwd@host:5672/another_virtual_host

The middleware can emit statistics on emitted events using tagged statsd metrics. This requires a DogStatsD compatible statsd service like the Prometheus StatsD exporter.

# turn on metrics
metrics_enabled = True

The default StatsD host and port can be customized using environment variables:

STATSD_HOST     the statsd hostname
STATSD_PORT     the statsd portnumber

The following metrics and dimensions are supported

The creation of audit events is driven by so called mapping rules. The CADF mapping rules are essentially a model of resources. Using OpenStack API design patterns, this model implies how the HTTP API requests are formed.

The path of an HTTP request specifies the resource that is the target of the request. It consists of a prefix and a resource path. The resource path is denoting the resource. The prefix is used for versioning and routing. Sometimes it is even used to specify the target project of an operation (e.g. in Cinder).

In the mapping file, the prefix is specified using a regular expression. In those cases where the prefix contains the target project id, the regular expression needs to capture the relevant part of the prefix using a named match group called project_id

prefix: '/v2.0/(?P<project_id>[0-9a-f\-]*)'

The resource path is a concatenation of resource names and IDs. URL paths follow one of the following patterns:

• /<resources>: HTTP POST for create, GET for list
• /<resources>/<resource-id>: HTTP GET for read, PUT for update, DELETE for remove
• /<resources>/<resource-id>/action: POST to perform an action specified by the payload. The payload is expressed as {<action>: {<parameter1>: <pvalue1>, ...}}
• /<resources>/<resource-id>/<custom-action>: perform a custom action specified in the mapping (otherwise this is interpreted as a key, see below)
• /<resources>/<resource-id>/<key>: update a key of a resource
• /<resources>/<resource-id>/<child-resource>: like top-level resource
• /<resources>/<resource-id>/<child-resource>/<child-resource-id>: like top-level resource

For singletons, i.e. resources with only a single instance, the <resource-id> parts are omitted.

Additional hints are added to address exceptions to these design patterns.

The mapping file starts with general information on the service:

• service_type: The type of service according to the CADF type taxonomy, i.e. the root of the type hierarchy. All resources of the service are added beneath that root.

• prefix: The URL prefix used by the service. Some OpenStack services specify the target project/domain in the URL, others rely on the authorization scope or special parameters.

    # service type as configured in the OpenStack catalog
    service_type: compute
    # configure prefix, use the named match group 'project_id' to mark the tenant
    prefix: '/v2[0-9\.]*/(?P<project_id>[0-9a-f\-]*)'
  

This is followed by a description of the service’s resource hierarchy.

The following defines a resource with the typeURI compute/servers.

     resources:
        servers:
            # type_uri: compute/servers (default)
            # el_type_uri: compute/server (default)
        custom_actions:
          startup: start/startup
        custom_attributes:
          # always attach the security_groups attribute value
          # which has type compute/server/security-groups
          security_groups: compute/server/security-groups

In addition to the basic resource actions implied by the HTTP method, OpenStack services can expose custom actions that go beyond CRUD. Two ways how to encoded action names in the HTTP request are common:

• payload-encoded: the last component of the URL path is the action name (example)
• path-encoded: the last component of the URL path is action and the payload contains the action name as the first JSON element (example

Usually all custom actions should be listed in the mapping because otherwise the last path component will be taken as a custom key of the resource or ignored right-away:

• custom_actions: map custom action names to the CADF action taxonomy (default: []).

The mapping of actions is complex: For payload-encoded actions a default-mapping will be applied which determines the primary action (e.g. update) from the HTTP method and adds the action name from the payload (e.g. update/myaction).

For path-encoded actions you can reach a similar behaviour with a generic rule of the form "<method>:*": "<action>" (e.g. "POST:*": "read"). You can refer to the actual action name in the path via * (e.g. "POST:*": "update/*"). If the right side of the rule is null, the entire request will be suppressed, so that no event is emitted (e.g. "POST:*": null).

If there is no rule matching the path suffix, it will be interpreted as a key, not as an action. That means that the action will be determined from the HTTP method only and an attachment with the name key and the name of the key as content will be added to the event.

Attributes of special importance can be added to every update-like event by specifying custom attributes:

• custom_attributes: list attributes of special importance whose values should always be attached to the event; Assign a type URI, so they can be shown in UIs properly (default: [])

A singleton resource is a api url call that will always lead to only one resource. Some resources exist only once, i.e. they only have a single instance and thus no unique ID. This is controlled by the following attribute:

• singleton: true when only a single instance of a resource exists. Otherwise the resource is a collection, i.e. an ID needs to be specified for address individual resource instances in a URL (default: false)

For some resources, some API designs do not follow the common OpenStack naming patterns. Those exceptions can be modelled with the following settings:

• api_name: resource name in the URL path (default: <resource-name>); must be unique
• type_uri: type-URI of the resource, used in the target.typeURI attribute of the produced CADF event (default: <parent-typeURI>/<resource-name>)
• el_type_uri: type-URI of the resource instances (default: type_uri omitting the last character); not applicable to singletons
• custom_id: indicate which resource attribute contains the unique resource ID (default: id)
• custom_name: indicate which resource attribute contains the resource readable name (default: name)
• type_name: JSON name for the resource, used by API designs that wrap the resource attributes into a single top-level attribute (default: api_name without leading os- prefix resp. the original resource name, but with - replaced by _)
• el_type_name: JSON name of the resource instances (default: type_name omitting the last character)

Resources can be nested, meaning that a resource is part of another resource. Nesting is used to model various design patterns:

• composition: a resource is really part of another resource, so that e.g. the resource is deleted when its parent is deleted.

• grouping: a singleton resource is used to group related resources or custom fields.

  children:
    metadata:
      # collection of fields/keys
      singleton: true
      # wrapped in a JSON element named "meta"
      type_name: meta
    migrations:
      # defaults are all fine for this resource
    interfaces:
      # for some reason Nova does not use plural for the os-interfaces of a server
      api_name: 'os-interface'
      # in JSON payloads the resource attributes are wrapped in an element called 'interfaceAttachment'
      type_name: interfaceAttachments
      # the unique ID of an os-interface is located in attribute 'port_id' (not 'id')
      custom_id: port_id
  

The configuration option to record request payloads needs some special consideration when sensitive or bulky information in involved:

• payloads: controls which attributes of the request payload may not be attached to the event (e.g. because they contain very sensitive information)
  • enabled: set to false to disable payload recording for this resource entirely (default: true)
  • exclude: exclude these payload attributes from the payload attachment (black-list approach, default: [])
  • include: only include these payload attributes in the payload attachment(white-list approach, default: all)

In our example this looks like this:

      ...
      os-server-password:
           singleton: true
        payloads:
          # never record payloads for the os-server-password resource
          enabled: False
flavors:
  payloads:
    exclude:
      # filter lengthy fields with no real diagnostic value
      - description
      - links

Resources that are not declared in the mapping file will be reported as unknown in the operational logs. Still the middleware tries to create events for them based on heuristics. They can be recognized by the X prefix in the resource name.

When those X-resources show up, the mapping file should be extended with an appropriate resource definition. The reason is that the heuristics to discover and map undeclared resources are not covering all kinds of requests. There are ambiguities.

This project is open for external contributions. The issue list shows what is planned for upcoming releases.

Pull-requests are welcome as long as you follow a few rules:

• Ensure that the middleware cannot degrade availabilty (no crashes, no deadlocks, no synchronous remote calls)
• Do not degrade performance
• Include unit tests for new or modified code
• Pass the static code checks
• Keep the architecture intact, don’t add shortcuts, layers, …

The purpose of this middleware is to create audit records from API calls.

Each record describes a user or system activity following the 5W1H principle:

• who: which user?
• what: which action? which parameters?
• where: on which target resource?
• when: what timestamp?
• why: which service URL?
• how: with what outcome (outcome, HTTP response code)

This information is gathered from the URL path and the exchanged payloads which may contain important information like resource IDs or names. Discovering that information based on the hints in the mapping file is what most of the code is about.

Complexity comes from:

• different styles of encoding actions and payloads
• create calls, where the target resource ID needs to be fetched from the result payload
• mass vs. single operations

Components/Packages

• api: Implementation of actual pipeline filter
• notifier: Implementation of the asynchronous event push to the oslo bus
• tests: unit and component tests

Paste middleware to produce a CADF audit trail from OpenStack API calls. Currently the following OpenStack services are supported out-of-the-box today:

• Nova
• Neutron
• Cinder
• Designate
• Manila
• Glance
• Barbican
• Ironic
• Octavia

Additional APIs can be supported without major code changes through templates.

It is a major redesign of the original audit module within the keystonemiddleware. It has been invented to produce a more verbose audit trail that can be consumed by auditors, end users and complex event processing infrastructures alike.

For that reason it does not adhere to the existing OpenStack taxonomy for CADF. The biggest difference is that it populates the target part of the CADF event with the actual resource/object affected by the action. This is a prerequisite to user friendly presentation of events, e.g. navigation from event to target objects. Previously, the essential information which target object has been affected by an audit-relevant action had been buried in the requestPath attribute or was not available at all.

For operators the difference is minor though. The integration of the new middleware in the OpenStack service works the same way with the only change being different mapping files and of course the new binaries.

The figure above shows the middleware in Nova’s pipeline.

To enable auditing, oslo.messaging should be installed. If not, the middleware will write audit events to the application log instead.

Auditing is enabled by editing the services’s api-paste.ini file to include the following filter definition:

[filter:audit]
paste.filter_factory = auditmiddleware:filter_factory
audit_map_file = /etc/nova/api_audit_map.yaml

The filter must be included after Keystone middleware’s authtoken filter so it can utilise request header variables set by it.

Below is an example using Nova’s WSGI pipeline::

[composite:openstack_compute_api_v2]
use = call:nova.api.auth:pipeline_factory
noauth = faultwrap sizelimit noauth ratelimit osapi_compute_app_v2
keystone = faultwrap sizelimit authtoken keystonecontext ratelimit audit osapi_compute_app_v2
keystone_nolimit = faultwrap sizelimit authtoken keystonecontext audit osapi_compute_app_v2

To properly audit api requests, the audit middleware requires a mapping file. The mapping files describes how to generate CADF events out of REST API calls.

The location of the mapping file should be specified explicitly by adding the path to the audit_map_file option of the filter definition::

[filter:audit]
paste.filter_factory = auditmiddleware:filter_factory
audit_map_file = /etc/nova/api_audit_map.yaml

For each supported OpenStack services, a mapping file named <service>_api_audit_map.yaml is included in the etc folder of this repo.

Additional options can be set:

Certain types of HTTP requests can be ignored entirely. Typically GET and HEAD requests should not cause the creation of an audit events due to sheer volume.

# ignore any GET or HEAD requests
ignore_req_list = GET, HEAD

The payload of the API response to a CRUD request can be attached to the event optionally. This will increase the size of the events, but brings a lot of value when it comes to diagnostics. Sensitive information can be filtered out using the payloads attribute of the resource mapping specification (see below).

# turn on logging on request payloads
record_payloads = True

Audit middleware can be configured to use its own exclusive notification driver and topic(s) value. This can be useful when the service is already using oslo messaging notifications and wants to use a different driver for auditing e.g. service has existing notifications sent to queue via ‘messagingv2’ and wants to send audit notifications to a log file via ‘log’ driver.

The oslo messaging configuration for the audit middleware is at the same place as service’s oslo messaging configuration: the service configuration file (e.g. neutron.conf)

Example shown below:

[audit_middleware_notifications]
driver = log

When audit events are sent via ‘messagingv2’ or ‘messaging’, middleware can specify a transport URL if its transport URL needs to be different from the service’s own messaging transport setting. Other Transport related settings are read from oslo messaging sections defined in service configuration e.g. ‘oslo_messaging_rabbit’.

Example shown below:

[audit_middleware_notifications]
driver = messagingv2
transport_url = rabbit://user2:passwd@host:5672/another_virtual_host

The middleware can emit statistics on emitted events using tagged statsd metrics. This requires a DogStatsD compatible statsd service like the Prometheus StatsD exporter.

# turn on metrics
metrics_enabled = True

The default StatsD host and port can be customized using environment variables:

STATSD_HOST     the statsd hostname
STATSD_PORT     the statsd portnumber

The following metrics and dimensions are supported

The creation of audit events is driven by so called mapping rules. The CADF mapping rules are essentially a model of resources. Using OpenStack API design patterns, this model implies how the HTTP API requests are formed.

The path of an HTTP request specifies the resource that is the target of the request. It consists of a prefix and a resource path. The resource path is denoting the resource. The prefix is used for versioning and routing. Sometimes it is even used to specify the target project of an operation (e.g. in Cinder).

In the mapping file, the prefix is specified using a regular expression. In those cases where the prefix contains the target project id, the regular expression needs to capture the relevant part of the prefix using a named match group called project_id

prefix: '/v2.0/(?P<project_id>[0-9a-f\-]*)'

The resource path is a concatenation of resource names and IDs. URL paths follow one of the following patterns:

• /<resources>: HTTP POST for create, GET for list
• /<resources>/<resource-id>: HTTP GET for read, PUT for update, DELETE for remove
• /<resources>/<resource-id>/action: POST to perform an action specified by the payload. The payload is expressed as {<action>: {<parameter1>: <pvalue1>, ...}}
• /<resources>/<resource-id>/<custom-action>: perform a custom action specified in the mapping (otherwise this is interpreted as a key, see below)
• /<resources>/<resource-id>/<key>: update a key of a resource
• /<resources>/<resource-id>/<child-resource>: like top-level resource
• /<resources>/<resource-id>/<child-resource>/<child-resource-id>: like top-level resource

For singletons, i.e. resources with only a single instance, the <resource-id> parts are omitted.

Additional hints are added to address exceptions to these design patterns.

The mapping file starts with general information on the service:

• service_type: The type of service according to the CADF type taxonomy, i.e. the root of the type hierarchy. All resources of the service are added beneath that root.

• prefix: The URL prefix used by the service. Some OpenStack services specify the target project/domain in the URL, others rely on the authorization scope or special parameters.

    # service type as configured in the OpenStack catalog
    service_type: compute
    # configure prefix, use the named match group 'project_id' to mark the tenant
    prefix: '/v2[0-9\.]*/(?P<project_id>[0-9a-f\-]*)'
  

This is followed by a description of the service’s resource hierarchy.

The following defines a resource with the typeURI compute/servers.

     resources:
        servers:
            # type_uri: compute/servers (default)
            # el_type_uri: compute/server (default)
        custom_actions:
          startup: start/startup
        custom_attributes:
          # always attach the security_groups attribute value
          # which has type compute/server/security-groups
          security_groups: compute/server/security-groups

In addition to the basic resource actions implied by the HTTP method, OpenStack services can expose custom actions that go beyond CRUD. Two ways how to encoded action names in the HTTP request are common:

• payload-encoded: the last component of the URL path is the action name (example)
• path-encoded: the last component of the URL path is action and the payload contains the action name as the first JSON element (example

Usually all custom actions should be listed in the mapping because otherwise the last path component will be taken as a custom key of the resource or ignored right-away:

• custom_actions: map custom action names to the CADF action taxonomy (default: []).

The mapping of actions is complex: For payload-encoded actions a default-mapping will be applied which determines the primary action (e.g. update) from the HTTP method and adds the action name from the payload (e.g. update/myaction).

For path-encoded actions you can reach a similar behaviour with a generic rule of the form "<method>:*": "<action>" (e.g. "POST:*": "read"). You can refer to the actual action name in the path via * (e.g. "POST:*": "update/*"). If the right side of the rule is null, the entire request will be suppressed, so that no event is emitted (e.g. "POST:*": null).

If there is no rule matching the path suffix, it will be interpreted as a key, not as an action. That means that the action will be determined from the HTTP method only and an attachment with the name key and the name of the key as content will be added to the event.

Attributes of special importance can be added to every update-like event by specifying custom attributes:

• custom_attributes: list attributes of special importance whose values should always be attached to the event; Assign a type URI, so they can be shown in UIs properly (default: [])

A singleton resource is a api url call that will always lead to only one resource. Some resources exist only once, i.e. they only have a single instance and thus no unique ID. This is controlled by the following attribute:

• singleton: true when only a single instance of a resource exists. Otherwise the resource is a collection, i.e. an ID needs to be specified for address individual resource instances in a URL (default: false)

For some resources, some API designs do not follow the common OpenStack naming patterns. Those exceptions can be modelled with the following settings:

• api_name: resource name in the URL path (default: <resource-name>); must be unique
• type_uri: type-URI of the resource, used in the target.typeURI attribute of the produced CADF event (default: <parent-typeURI>/<resource-name>)
• el_type_uri: type-URI of the resource instances (default: type_uri omitting the last character); not applicable to singletons
• custom_id: indicate which resource attribute contains the unique resource ID (default: id)
• custom_name: indicate which resource attribute contains the resource readable name (default: name)
• type_name: JSON name for the resource, used by API designs that wrap the resource attributes into a single top-level attribute (default: api_name without leading os- prefix resp. the original resource name, but with - replaced by _)
• el_type_name: JSON name of the resource instances (default: type_name omitting the last character)

Resources can be nested, meaning that a resource is part of another resource. Nesting is used to model various design patterns:

• composition: a resource is really part of another resource, so that e.g. the resource is deleted when its parent is deleted.

• grouping: a singleton resource is used to group related resources or custom fields.

  children:
    metadata:
      # collection of fields/keys
      singleton: true
      # wrapped in a JSON element named "meta"
      type_name: meta
    migrations:
      # defaults are all fine for this resource
    interfaces:
      # for some reason Nova does not use plural for the os-interfaces of a server
      api_name: 'os-interface'
      # in JSON payloads the resource attributes are wrapped in an element called 'interfaceAttachment'
      type_name: interfaceAttachments
      # the unique ID of an os-interface is located in attribute 'port_id' (not 'id')
      custom_id: port_id
  

The configuration option to record request payloads needs some special consideration when sensitive or bulky information in involved:

• payloads: controls which attributes of the request payload may not be attached to the event (e.g. because they contain very sensitive information)
  • enabled: set to false to disable payload recording for this resource entirely (default: true)
  • exclude: exclude these payload attributes from the payload attachment (black-list approach, default: [])
  • include: only include these payload attributes in the payload attachment(white-list approach, default: all)

In our example this looks like this:

      ...
      os-server-password:
           singleton: true
        payloads:
          # never record payloads for the os-server-password resource
          enabled: False
flavors:
  payloads:
    exclude:
      # filter lengthy fields with no real diagnostic value
      - description
      - links

Resources that are not declared in the mapping file will be reported as unknown in the operational logs. Still the middleware tries to create events for them based on heuristics. They can be recognized by the X prefix in the resource name.

When those X-resources show up, the mapping file should be extended with an appropriate resource definition. The reason is that the heuristics to discover and map undeclared resources are not covering all kinds of requests. There are ambiguities.

This project is open for external contributions. The issue list shows what is planned for upcoming releases.

Pull-requests are welcome as long as you follow a few rules:

• Ensure that the middleware cannot degrade availabilty (no crashes, no deadlocks, no synchronous remote calls)
• Do not degrade performance
• Include unit tests for new or modified code
• Pass the static code checks
• Keep the architecture intact, don’t add shortcuts, layers, …

The purpose of this middleware is to create audit records from API calls.

Each record describes a user or system activity following the 5W1H principle:

• who: which user?
• what: which action? which parameters?
• where: on which target resource?
• when: what timestamp?
• why: which service URL?
• how: with what outcome (outcome, HTTP response code)

This information is gathered from the URL path and the exchanged payloads which may contain important information like resource IDs or names. Discovering that information based on the hints in the mapping file is what most of the code is about.

Complexity comes from:

• different styles of encoding actions and payloads
• create calls, where the target resource ID needs to be fetched from the result payload
• mass vs. single operations

Components/Packages

• api: Implementation of actual pipeline filter
• notifier: Implementation of the asynchronous event push to the oslo bus
• tests: unit and component tests

⛔️ This project has been deprecated and will not receive any regular maintenance.

The preferred authentication method for OpenStreetMap is now OAuth2, therefore this library isn’t used anymore.

A most-of-the-way OAuth 1.0 client implementation in Javascript. Meant to be an improvement over the default linked one because this uses idiomatic Javascript.

If you use this on a server different from the one authenticated against, you’ll need to enable and use CORS for cross-origin resources. CORS is not available in IE before version IE10.

Try it out at: http://osmlab.github.io/ohauth/

As a file

wget https://raw.github.com/osmlab/ohauth/gh-pages/ohauth.js

With browserify

npm install ohauth
var ohauth = require('ohauth');

• OpenStreetMap full & tested with iD
• GitHub – partial, full flow is not possible because access_token API is not CORS-enabled

// generates an oauth-friendly timestamp
ohauth.timestamp();

// generates an oauth-friendly nonce
ohauth.nonce();

// generate a signature for an oauth request
ohauth.signature("myOauthSecret", "myTokenSecret", "percent&encoded&base&string");

// make an oauth request.
ohauth.xhr(method, url, auth, data, options, callback);

// options can be a header like
{ header: { 'Content-Type': 'text/xml' } }

ohauth.xhr('POST', url, o, null, {}, function(xhr) {
    // xmlhttprequest object
});

// generate a querystring from an object
ohauth.qsString({ foo: 'bar' });
// foo=bar

// generate an object from a querystring
ohauth.stringQs('foo=bar');
// { foo: 'bar' }

// create a function holding configuration
var auth = ohauth.headerGenerator({
    consumer_key: '...',
    consumer_secret: '...'
});

// pass just the data to produce the OAuth header with optional
// POST data (as long as it'll be form-urlencoded in the request)
var header = auth('GET', 'http://.../?a=1&b=2', { c: 3, d: 4 });
// or pass the POST data as an form-urlencoded
var header = auth('GET', 'http://.../?a=1&b=2', 'c=3&d=4');

⛔️ This project has been deprecated and will not receive any regular maintenance.

The preferred authentication method for OpenStreetMap is now OAuth2, therefore this library isn’t used anymore.

A most-of-the-way OAuth 1.0 client implementation in Javascript. Meant to be an improvement over the default linked one because this uses idiomatic Javascript.

If you use this on a server different from the one authenticated against, you’ll need to enable and use CORS for cross-origin resources. CORS is not available in IE before version IE10.

Try it out at: http://osmlab.github.io/ohauth/

As a file

wget https://raw.github.com/osmlab/ohauth/gh-pages/ohauth.js

With browserify

npm install ohauth
var ohauth = require('ohauth');

• OpenStreetMap full & tested with iD
• GitHub – partial, full flow is not possible because access_token API is not CORS-enabled

// generates an oauth-friendly timestamp
ohauth.timestamp();

// generates an oauth-friendly nonce
ohauth.nonce();

// generate a signature for an oauth request
ohauth.signature("myOauthSecret", "myTokenSecret", "percent&encoded&base&string");

// make an oauth request.
ohauth.xhr(method, url, auth, data, options, callback);

// options can be a header like
{ header: { 'Content-Type': 'text/xml' } }

ohauth.xhr('POST', url, o, null, {}, function(xhr) {
    // xmlhttprequest object
});

// generate a querystring from an object
ohauth.qsString({ foo: 'bar' });
// foo=bar

// generate an object from a querystring
ohauth.stringQs('foo=bar');
// { foo: 'bar' }

// create a function holding configuration
var auth = ohauth.headerGenerator({
    consumer_key: '...',
    consumer_secret: '...'
});

// pass just the data to produce the OAuth header with optional
// POST data (as long as it'll be form-urlencoded in the request)
var header = auth('GET', 'http://.../?a=1&b=2', { c: 3, d: 4 });
// or pass the POST data as an form-urlencoded
var header = auth('GET', 'http://.../?a=1&b=2', 'c=3&d=4');

Logging tenhou paifu into excel, csv or html file with some key information.

If you like this project, please leave a star. It will be a great encouragement for me. And if you have any suggestions, please feel free to create an issue.

Downloads | 繁體中文 | 简体中文 | 日本語

• Python 3.10 or later

Since CLI-0.3.8, the project is only compatible with Python 3.10 or later. For Python 3.9 or earlier users, please use CLI-0.3.7.1 which is the last version that supports Python 3.9 or earlier. Or download from pypi with the following command.

pip install PaifuLogger==0.3.7.1

1. Download the project.

a. Via GitHub.

i. Clone the repository or download the latest release.

git clone https://github.com/Jim137/Tenhou-Paifu-Logger.git

ii. Copy the paifu URL from tenhou.net to clipboard.

iii. Run runlog-user.bat or runlog-user.sh.

b. Via pypi.

i. Open terminal and install with pip command.

pip install PaifuLogger

ii. Copy the paifu URL from tenhou.net to clipboard. And run by

plog -l [language] -o [output directory] [paifu URLs]

paifu plog -l [language] -o [output directory] [paifu URLs]

2. Once Please enter the URL of match: appears, paste the URL and press Enter.
   Note: In the latest version, you can input multiple URLs at once, separated by whatever you like. If you are lazy, you can just paste w/o anything.
3. After Match of {paifu name} has been recorded appears, the paifu has been successfully logged.

You can manually log the paifu by the following code.

from paifulogger import get_log_func, get_paifu, localized_str, log_paifu

url = "Your paifu URL"
local_lang = localized_str("en") # Localization
log_formats = get_log_func(["csv", "html"]) # Log into csv and html file.
output = "./" # Output directory
mjai = False # Whether have output in mjai format

# Log the paifu into the file.
log_paifu(
    url,
    log_formats = log_formats,
    local_lang = local_lang,
    output = output,
    mjai = mjai
)
# Get Paifu object, which contains all the information of the paifu.
paifu = get_paifu(url, local_lang)

• Support multiple URLs at once.
• Log paifu into excel, csv or html file with some key information. (-f, –format)
• Support logging to multiple formats at once. (e.g.: -f csv -f html; -a, –all-formats)
• Distinguish Sanma(3p) and Yonma(4p) and log into separate sheets.
• Skip duplicated paifu
• Remake the paifu with URL already logged (-r, –remake). It will be useful when we updated the logging information in future.
• Customized output directory (-o, –output)
• Support mjai format paifu output (–mjai). You have to run git pull --recurse-submodules first.
• Localization support (-l, –language)
  • English: en
  • Traditional Chinese: zh_tw
  • Simplified Chinese: zh
  • Japanese (ChatGPT): ja
• Support config file. Placing config.json in the same directory as the execution enables local configuration. For global configuration, place it in the following directories:
  • Windows: %localappdata%\Jim137\paifulogger\config.json
  • macOS: /Users/{UserName}/Library/Application Support/paifulogger/config.json
  • Linux: ~/.local/share/paifulogger/config.json
• Support logging from Tenhou client(*.mjlog). (-c, –from-client DIR_TO_MJLOG)
  Note: Typically, the saved directory is {Documents}/My Tenhou/log/ on Windows.
• Match replay for html format. By clicking the match you want to review, the match replay will pop up accordingly.

• Game time
• Placing
• URL (for future use)
• Rate before the game
• The change of Rate: Note it assumes that the player has played more than 400 games.
• Number of wins
• Number of deal-ins

• Agari analysis
• Support Majsoul paifu
• GUI

We welcome all kinds of contributions, including but not limited to bug reports, pull requests, feature requests, documentation improvements, localizations…etc.

See CONTRIBUTING.md for more details.

This project is licensed under the MIT License – see the LICENSE file for details.

Welcome to Project Blue Green, this open-source repository is your gateway to participating in the ongoing development of an efficient algae bioreactor, combining state-of-the-art technology with a DIY approach. Dive into the world of AI, ML, and IoT to cultivate algae effortlessly and contribute to a greener future.

Code repository for Project Blue Green Software
Report Issues · Request Feature · Send a Pull Request · Community Discussions

• Inclusive Technology: Unlock the potential of AI, ML, and IoT to streamline algae growth. Our design prioritizes accessibility, ensuring that even beginners can set up and manage their bioreactors with ease.
• Open-Source Innovation: Embrace collaboration! From hardware and software to biochemistry, our project is open for contributions. Modify, enhance, and adapt – we’re building a community-driven initiative.
• Simplified DIY: Transform algae bioreactor construction into a DIY adventure. You don’t need to be a tech guru; follow our user-friendly guide, and you’ll be on your way to having your sustainable algae cultivation system up and running in no time.

1. Project Objectives
2. Getting Started
3. Resources
4. Open Source Contribution
5. License

• Optimal Efficiency: Project Blue Green is actively working to create the world’s most advanced yet straightforward algae bioreactor design. Through AI and ML algorithms, we’re fine-tuning the process for maximum efficiency, making sustainable practices accessible to all.
• Climate Change Awareness: More than just hardware and code, our documentation includes crucial information on climate change and global warming. Understand the environmental impact and join us in inspiring action for a cleaner, greener planet.
• Community Engagement: Join a community in the making, dedicated to positive environmental change. Whether you actively participate in development, contribute ideas, or support us through donations, every effort contributes to a more sustainable world.

• Follow our straightforward instructions in the Documentation to start exploring and contributing to the ongoing development of your own algae bioreactor.
• Contribute, share, and let’s collaborate to make Project Blue Green a driving force for sustainable practices worldwide.
• Join Project Blue Green, and be a part of shaping the movement towards a more sustainable and eco-friendly future! (Note: This project is currently under active development and is not yet complete.)

• Check AI ML integration on Arduino Nano 33 BLE Sense Board

Contributions are what make the open source community such an amazing place to be learn, inspire, and create. Any contributions you make are extremely appreciated. See the open issues for a list of proposed features (and known issues).

1. Fork the Project
2. Create your Feature Branch (git checkout -b feature/AmazingFeature)
3. Commit your Changes (git commit -m 'Add some AmazingFeature')
4. Push to the Branch (git push origin feature/AmazingFeature)
5. Open a Pull Request

• Distributed under the GNU License

Welcome to Project Blue Green, this open-source repository is your gateway to participating in the ongoing development of an efficient algae bioreactor, combining state-of-the-art technology with a DIY approach. Dive into the world of AI, ML, and IoT to cultivate algae effortlessly and contribute to a greener future.

Code repository for Project Blue Green Software

Report Issues
·
Request Feature
·
Send a Pull Request
·
Community Discussions

• Inclusive Technology:
  Unlock the potential of AI, ML, and IoT to streamline algae growth. Our design prioritizes accessibility, ensuring that even beginners can set up and manage their bioreactors with ease.
• Open-Source Innovation:
  Embrace collaboration! From hardware and software to biochemistry, our project is open for contributions. Modify, enhance, and adapt – we’re building a community-driven initiative.
• Simplified DIY:
  Transform algae bioreactor construction into a DIY adventure. You don’t need to be a tech guru; follow our user-friendly guide, and you’ll be on your way to having your sustainable algae cultivation system up and running in no time.

1. Project Objectives
2. Getting Started
3. Resources
4. Open Source Contribution
5. License

• Optimal Efficiency:
  Project Blue Green is actively working to create the world’s most advanced yet straightforward algae bioreactor design. Through AI and ML algorithms, we’re fine-tuning the process for maximum efficiency, making sustainable practices accessible to all.
• Climate Change Awareness:
  More than just hardware and code, our documentation includes crucial information on climate change and global warming. Understand the environmental impact and join us in inspiring action for a cleaner, greener planet.
• Community Engagement:
  Join a community in the making, dedicated to positive environmental change. Whether you actively participate in development, contribute ideas, or support us through donations, every effort contributes to a more sustainable world.

• Follow our straightforward instructions in the Documentation to start exploring and contributing to the ongoing development of your own algae bioreactor.
• Contribute, share, and let’s collaborate to make Project Blue Green a driving force for sustainable practices worldwide.
• Join Project Blue Green, and be a part of shaping the movement towards a more sustainable and eco-friendly future! (Note: This project is currently under active development and is not yet complete.)

• Check AI ML integration on Arduino Nano 33 BLE Sense Board

Contributions are what make the open source community such an amazing place to be learn, inspire, and create. Any contributions you make are extremely appreciated. See the open issues for a list of proposed features (and known issues).

1. Fork the Project
2. Create your Feature Branch (git checkout -b feature/AmazingFeature)
3. Commit your Changes (git commit -m 'Add some AmazingFeature')
4. Push to the Branch (git push origin feature/AmazingFeature)
5. Open a Pull Request

• Distributed under the GNU License

Description: For my Digital Bike Speedometer, i have a Hall Effect Sensor connected to an LCD screen. The Hall Effect sensor should be connected to a static position on a bike near the wheel. Then, a Magnet should be attached to the wheel. When the magnet passes the Sensor, a value of High is received by the Arduino. The Code then uses the wheels diameter and the amount of revolutions to determine the speed and distance travelled of the bike. Then, it will print these values to the LCD screen.

Equipment needed:

• Arduino
• Hall Effect Sensor
• Magnet
• LCD screen (16×2)
• Power Source (7V-12V battery)
• Battery Connector
• 2 way switch
• Breadboard
• Wires
• Function for calculating Speed and Distance (code)

Other Practical Skills needed: Programming, Soldering, Web Development, Wiring, Digital Electronics, Math.

This is the code that updates the Speed and Distance variables for my project;

void updateSpeedAndDistance()
{
  distance = tire_circumference * revolutions;
  distance /= miles_in_inches;
  float ipm = tire_circumference / (float)last_interval;
  mph = ipm * k_ipm_2_mph;
}

This is the code that prints the values to the LCD Screen;

void loop()                                                  // Continuously loops over following code to update the variables "mph" and "distance"
{
  int hall_val = digitalRead(2);
  if (hall_state != hall_val && hall_val == LOW)
  {
   revolutions++;
   last_interval = millis()-last_fall;
   last_fall = millis();
 }

 hall_state = hall_val;
 updateSpeedAndDistance();                                   // Calls "updateSpeedAndDistance" function here

 lcd.setCursor(0, 0);                                        // Sets Cursor to first row first column
 lcd.print("Mph:");                                          // Prints "Mph" on screen
 lcd.print(mph);                                       // Prints value for Mph on screen
 lcd.setCursor(0, 1);                                        // Sets Cursor to first row second column
 lcd.print("Miles:");                                        // Prints "Miles" on screen
 lcd.print(distance);                                        // Prints value for distance on screen
}

Daniel Collins 20076240