[feature] RADIUS Timeseries Charts

[nemesifier]

A number of changes will be made to the OpenWISP RADIUS and OpenWISP Monitoring modules which will make it possible to store RADIUS session data in anonymised form (i.e. personal user data contained in RADIUS session details will be obfuscated with hashing techniques such as "sha1") and user registrations, this will allow a retention of statistical data beyond 12/18 months for analysis purposes by the user without violating privacy and data retention laws.

The data will be stored in the timeseries database (InfluxDB) according to the already adopted retention policy which can be changed upon request.

This feature must be disabled by default and implemented in a separate optional sub module of openwisp-radius (in a similar way as we have created an integration modules in network-topology).

The snapshotting of the radius accounting sessions into influxdb could be done each time a radius session is flagged as closed.
The snapshotting of total sign ups could be done daily at the end of each day.
The daily sign ups timeseries data could be stored whenever a new user signs up and completes the verification process, or it could be taken at the end of each day too, as long as the solution meets the requirements and it's scalable we can be flexible with the implementation details.

Time Period

It will be possible to change the period of the timeseries data by going back in time, the minimum period that can be viewed will be one day, the maximum period that can be viewed will be a year, it will be possible to select the dates of interest and the grouping of statistical data over a long period will be one day, i.e. each point on the graph will represent a specific date.

CSV export

It will also be possible to export the data in CSV format, similar to how it already happens for the monitoring data of the devices.

The graphs that will be added are listed below and indicative graphical examples are provided.

Permission to view statistics (read only)

The system will allow the definition of user profiles who will have read-only access to the administration interface who will be able to view the statistical data without making any changes.

New daily sign up charts

It will allow to obtain the following information:

• How many users have signed up each day over time
• Of the users who register every day, it will be possible to know the breakdown by identity verification method (eg: telephone number, credit card, SPID)
• The summary part below will allow you to know the total number of users who registered in the selected period (total users, users registered with telephone number, users registered with credit card, users who registered using SPID).

Cumulative sign ups charts

It will allow to obtain the following information:

• How many total users are registered in the system on a given date
• Of the total users registered for each date, it will be possible to know the breakdown by identity verification method (eg: telephone number, credit card, SPID)
• The summary part below will allow you to have the total number of users present in the system at the end of the selected period (total users or divided by telephone number, credit card, SPID).

RADIUS session traffic

It will allow to obtain the following information:

• How much traffic was made by users who used the WiFi after authenticating, each bar will allow you to understand how much of the traffic on that particular date is made up of download or upload traffic, it will also be possible to view the total traffic for each day.
• The summary part below will allow you to know the total traffic made during the selected period (download traffic, upload traffic, total traffic).

RADIUS sessions count

It will allow to obtain the following information:

• How many users authenticated each day to the WiFi service.
• It will also be possible to view the subdivision by access registration method, i.e. how many sessions have been initialized by users who registered with their telephone number, credit card or SPID.
• It will also be possible to know how many unique accesses have been made, i.e. if a user has carried out multiple sessions during the day, these will only be counted as a single access
• The summary part below will allow you to know the total number of accesses made during the selected period and divided by: total accesses, unique accesses, accesses by users registered with their telephone number, accesses by users registered with a credit card, accesses of users who authenticate with SPID.

Access and traffic statistics by device

The statistical data of the RADIUS sessions will also be shown on the WiFi devices page, it will therefore be possible to know, for each device:

• The traffic made by users authenticated to the WiFi service
• The number of total, unique and broken down by registration method logins

Ability to filter general data by organization

On the main page of the system, users will be able to view and export the data of all organizations they have access to.

If the user has access to multiple organizations, the system will present the following possibilities:

• view/export data of all the organizations it manages (default)
• view/export the data of the selected organization

[pandafy]

The integration will write to the user signup metric in two conditions:

1. When RegisteredUser object is created
2. When OrganizationUser object is created

Now considering this scenario where a user is member of two organizations, two points will be written to the InfluxDB (one for each organization). When a superuser will look at the user registration chart on the dashboard, it will show twice the number of users:

Is this side-effect correct?

[nemesifier]

The integration will write to the user signup metric in two conditions:

1. When RegisteredUser object is created
2. When OrganizationUser object is created

Now considering this scenario where a user is member of two organizations, two points will be written to the InfluxDB (one for each organization). When a superuser will look at the user registration chart on the dashboard, it will show twice the number of users:

Is this side-effect correct?

Good catch, when counting the amount of users for superusers, can we do a distinct on the field which identifies the user? So we discard the same user being subscribed to multiple organizations?