Multiple Transactions Allowed with Same connectorId and idTag

[Tano-Coppoletta]

Issue Description:
The current implementation of the OCPP server does not adhere to the specified behavior in the OCPP documentation regarding concurrent transactions. The documentation states that if an idTag is already involved in an active transaction, any attempt to initiate a new transaction with the same idTag should result in an AuthorizationStatus of ConcurrentTx. However, I've observed two issues:

1. The server allows initiation of multiple transactions using the same idTag without the ConcurrentTx status.
2. A StopTransaction message with a random transactionId can stop the current transaction.

Steps to Reproduce:

1. Send a StartTransaction message using a specific idTag.
2. While the transaction is active, send another StartTransaction message with the same idTag.
3. Observe that the server does not return an AuthorizationStatus of ConcurrentTx.
4. Send a StopTransaction message with a random transactionId.
5. Note that the server stops the most recent transaction.

Expected Behavior:
In compliance with the OCPP specification, the server should not allow a new transaction to start with an idTag that is already in use for an ongoing transaction. The server should issue an AuthorizationStatus of ConcurrentTx.

Actual Behavior:
Multiple transactions are allowed for the same idTag without returning a ConcurrentTx status, and transactions can be stopped using random transactionIds.

Potential Impact:
This could cause a critical error in transaction management and billing processes, affecting operational integrity.

Suggested Solution:

• Update the server logic to return an AuthorizationStatus of ConcurrentTx for StartTransaction requests that involve an idTag in an ongoing transaction.
• Validate transactionId in StopTransaction requests to ensure the correct transaction is being stopped.

Best regards,
Gaetano Coppoletta

[dallmann-consulting]

You are correct. The specification describes the status "ConcurrentTx" this way. But does it make sense in real life?
Imagine you've got two cars in your family and want to charge both in parallel on the same account/token? Why should that be rejected?
I've added a configuration switch (appsettings.json) to enable this behavior (next version 1.3.0).
It might make more sense to add a corresponding setting to the charge tags. So it can be enabled/disabled individually. Maybe in a later version :-)

[dallmann-consulting]

Please check V1.3.0. There is an new switch in the appsettings file.