Server Performance Degradation Due to Unvalidated Message Acceptance

[Tano-Coppoletta]

Checklist

• I checked other issues already, but found no answer/solution
• I checked the documentation and wiki, but found no answer/solution
• I am running the latest version and the issue still occurs
• I am sure that this issue is about SteVe (and not about the charging station software or something unrelated to SteVe)

Specifications

SteVe Version     : 3.6.0
Operating system  : Ubuntu 22.04.1
JDK               : openjdk version "11.0.20.1"
Database          : version 1.0.3

Issue Description

The Steve OCPP server accepts and stores invalid messages without proper validation, which has been observed to cause significant performance degradation. The server becomes notably slow in responding to requests on the web interface, with transaction pages taking an excessive amount of time to load, often resulting in web browser timeouts or crashes.

Reproduction Steps

1. Send multiple invalid OCPP messages to the server.
2. Attempt to access transaction data or other information through the Steve web interface.
3. Experience prolonged load times, often leading to unresponsiveness or browser crashes.

Expected Behavior

The server should validate incoming messages against the OCPP specification and reject those that do not conform. This would prevent invalid data from being stored and ensure that the server remains responsive.

Actual Behavior

The server is storing invalid messages, causing an overload, which manifests as extremely long load times for transaction data and potential server unavailability.

Impact

This vulnerability can lead to denial of service for legitimate users attempting to access the web interface and manage transactions.

Suggested Solution

Implement thorough validation checks for all incoming OCPP messages and discard those that are not compliant with the specification. Additionally, consider introducing performance optimizations to handle large volumes of data more efficiently.

Evidence

Attached is a screenshot showing a load time of 9.3 minutes for the transactions page, indicating the severity of the issue.

[goekay]

slow loading transaction/tag pages is due to inefficient sql query. it is known and fixed and will be merged: #1219

the performance degradation is not due to unvalidated messages.

[lategoodbye]

@Tano-Coppoletta Could you please retest with branch issue1219 ?