-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/permanent delete person #579
Feature/permanent delete person #579
Conversation
… promise returned from the keycloak client is rejected, the prisma service will not be called to delete the user in the db. Also, some reformatting the code as per prettier conf.
…ate. Also, the tests ware updated.
Run yarn format
✅ Tests will run for this PR. Once they succeed it can be merged. |
|
GitGuardian id | Secret | Commit | Filename | |
---|---|---|---|---|
- | Stripe Webhook Secret | 3e5848c | .env | View secret |
- | Stripe Webhook Secret | 9b63bef | .env | 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 secrets safely. Learn here the best practices.
- Revoke and rotate these secrets.
- 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.
Our GitHub checks need improvements? Share your feedbacks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just minor suggestions.
Looks good to me.
Love the unit tests.
apps/api/src/auth/auth.service.ts
Outdated
const user = await this.personService.findOneByKeycloakId(keycloakId) | ||
|
||
//Check and throw if user is a beneficiary, organizer or corporate profile | ||
if (user?.beneficiaries?.length || user?.organizer || user?.companyId) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would change this to:
if (user?.beneficiaries?.length > 0
Seems more natural to read.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will adjust this later today.
) | ||
} | ||
|
||
return this.authenticateAdmin() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I am fine with this .then format.
But I think so far the common pattern is to use await.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made this decision because if, for some reason, the promise from Keycloak does not resolve successfully, I want to interrupt the chain and refrain from removing the user in the API database. I am unsure if this is possible when I use await for every promise.
Added functionality that is responsible for deleting a user account. There is a safeguard in place that prevents the deletion of corporate, beneficiary, or organizer profiles. Additionally, several tests were added to ensure the proper functioning of this feature.