Feat/merge in system text json branch; fixes #262

[lxatstariongroup]

Prerequisites

• I have written a descriptive pull-request title
• I have verified that there are no overlapping pull-requests open
• I have verified that I am following the COMET-SDK code style guidelines
• I have provided test coverage for my change (where applicable)

Description

[WIP] Feat/merge in system text json branch

To fix the problem, we should avoid logging the Iid directly. Instead, we can log a generic message that does not include any sensitive information. This way, we can still keep track of the event without exposing private data.

• Replace the logging statements that include emailAddress.Iid with a more generic message.
• Ensure that no sensitive information is logged.

To fix the problem, we should avoid logging sensitive information directly. Instead, we can log a generic message without including the sensitive emailAddress.Iid. This way, we still get the benefit of logging without exposing private data.

• Modify the logging statements to remove the inclusion of emailAddress.Iid.
• Ensure that the log messages are still informative enough for debugging purposes without exposing sensitive information.

To fix the problem, we should avoid logging sensitive information such as emailAddress.Iid. Instead, we can log a generic message that does not include any sensitive data. This change will ensure that private information is not exposed through log files.

• Modify the Logger.Trace calls to remove the inclusion of emailAddress.Iid.
• Update the log messages to be more generic and not include any sensitive information.

To fix the problem, we should avoid logging the Iid directly. Instead, we can log a sanitized or masked version of the Iid to ensure that sensitive information is not exposed. This can be achieved by hashing the Iid before logging it. We will use a cryptographic hash function to generate a fixed-length hash of the Iid, which will be logged instead of the raw Iid.

To fix the problem, we need to ensure that sensitive information is not logged. We can achieve this by either removing the logging statement or by masking the sensitive information before logging it. In this case, we will remove the logging statement to prevent any potential exposure of private information.

To fix the problem, we should avoid logging the telephoneNumber.Iid directly. Instead, we can log a generic message that does not include potentially sensitive information. This way, we maintain the logging functionality without risking the exposure of private data.

• Replace the logging statements that include telephoneNumber.Iid with more generic messages.
• Ensure that the new logging messages do not contain any sensitive information.

To fix the problem, we need to ensure that sensitive information is not logged. One way to achieve this is by redacting or omitting the sensitive information from the log messages. In this case, we can avoid logging the telephoneNumber.Iid directly.

• Identify the lines where sensitive information is logged.
• Modify the log messages to exclude sensitive information or replace it with a non-sensitive placeholder.
• Ensure that the changes do not affect the existing functionality of the code.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
72.4% Coverage on New Code
7.8% Duplication on New Code

See analysis details on SonarQube Cloud