Cn 40 case api initial version#1
Conversation
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 9566081 | Assigned | Generic Password | 22cb6be | src/test/resources/docker-compose.yml | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
🦙 MegaLinter status:
|
| Descriptor | Linter | Files | Fixed | Errors | Warnings | Elapsed time |
|---|---|---|---|---|---|---|
| shfmt | 1 | 1 | 0 | 0.01s | ||
| markdownlint | 2 | 15 | 0 | 0.53s | ||
| ✅ MARKDOWN | markdown-table-formatter | 2 | 0 | 0 | 0.26s | |
| prettier | 5 | 1 | 6 | 0.52s |
See detailed report in MegaLinter reports
AdamHawtin
left a comment
AdamHawtin
left a comment
There was a problem hiding this comment.
A few comments around sending messages which need some more discussion.
|
|
||
|
|
||
| queueconfig: | ||
| questionnaire-linked-event-routing-key: event.questionnaire.update No newline at end of file |
There was a problem hiding this comment.
I think rather than a routing key for these events we'll need a new topic. We're not currently using routing keys for different event types, we're just using a different topic for each event. A new topic will need to be set up in docker dev for this too, otherwise the case processor will error when it tries to send.
There was a problem hiding this comment.
Modified the logic to use the PubSub for now. with put endpoint response NOT_IMPLEMENTED Status
| public void sendMessage(String destinationTopic, Object message) { | ||
| MessageToSend messageToSend = new MessageToSend(); | ||
| messageToSend.setId(UUID.randomUUID()); | ||
| messageToSend.setDestinationTopic(destinationTopic); | ||
| messageToSend.setMessageBody(JsonHelper.convertObjectToJson(message)); | ||
|
|
||
| messageToSendRepository.save(messageToSend); | ||
| } |
There was a problem hiding this comment.
This might be something to have a discussion about, this way of sending messages requires the case processor to pick up the messages from the database and the send them to itself via PubSub, which may create more of a delay in the eventual processing than we want. The reason we have this pattern is to ensure we have a way to send messages fully transactionally (which the PubSub API doesn't support) which we need when sending messages during the processing of other messages to ensure we have fully transactional behaviour when acknowledging messages, I think in the context of an API call it should be safe to send directly via PubSub instead.
There was a problem hiding this comment.
Modified the logic to use the PubSub for now. with put endpoint response NOT_IMPLEMENTED Status
3 participants
No description provided.