Disabled logs that had a risk of sensitive information

[mjacquot1]

Since the log level is lowered to INFO, WARNING & INFO will now be sent to cloudwatch.

I commented out these logs as they run the risk of exposing user P-I-I, financial information, internal queries, and keys.

I recommend these (and other logs of these levels) be changed to DEBUG in the future for local development purposes.

[SailingSteve]

@mjacquot1 @DaleMcGrew
I understand the concern.

Without these log lines, there is no way to debug actions that require specific domains for API queries, and can't be tested locally. Most of these have to do with Cordova, which are rarely called, and have lower risk. I also think we have to trust that cloud watch is secure.

I haven't gone through these in detail, but I would recommend against making these changes

One possibilty is to create a new API endpoint that could temporarily turn on the log lines (and others TBD) when needed for on the production server debugging. Turning them on by changing the code, submitting PRs and waiting for them to get deployed would really slow down development.

[mjacquot1]

@SailingSteve
Where would this be tested then? Previously, the production server was set to ERROR logs only so these wouldn't have even been raised in Prod.

If there is a live testing server, then this would be better resolved by either setting them to DEBUG, and having the logging level set accordingly, or routing these logs to a log-stream with a short time to live. Currently, they route to log-streams that are set to never expire.

@Arjunsivakumar28