Closed raffaelfoidl closed 2 years ago
In GitLab by @11775820 on Oct 10, 2021, 02:03
Commented on server/src/test/java/com/witness/server/integration/infrastructure/test/SecurityInfrastructureController.java line 24
This integration-test
-only controller is a compromise between test coverage and independence of tests from production code. As you surely recognize, this controller is basically a copy of GreetingController
. This is done on purpose because GreetingController
will be discarded as soon as the project advances. As I really wanted to test the security (and especially integration test infrastructure), I cannot rely on some production controller that is subject to change and maybe does not offer all features needed to ensure correct behaviour of the SecurityFilter
etc. and BaseIntegrationTest
.
In GitLab by @11775820 on Oct 10, 2021, 02:03
requested review from @11712616
In GitLab by @11775820 on Oct 10, 2021, 12:29
added 5 commits
In GitLab by @11712616 on Oct 10, 2021, 14:19
Commented on server/src/main/java/com/witness/server/entity/User.java line 79
Is there a reason why you did not use Lombok's @EqualsAndHashCode
annotation?
https://projectlombok.org/features/EqualsAndHashCode
In GitLab by @11712616 on Oct 10, 2021, 14:19
Commented on server/src/main/java/com/witness/server/enumeration/ServerError.java line 57
Where/Why do we need a phone number? Is this necessary for mapping the Firebase errors?
In GitLab by @11712616 on Oct 10, 2021, 14:19
Commented on server/src/main/java/com/witness/server/exception/DataAccessException.java line 11
Do we really need the subtypes DataCreationException
and DataModificationException
? I am just wondering what benefit(s) you see in such a fine granularity since all three exceptions map to a 500 Internal Server Error
.
In GitLab by @11712616 on Oct 10, 2021, 14:19
Commented on server/src/main/java/com/witness/server/exception/InsufficientRightsException.java line 11
InsufficientRightsException
sounds really dramatic in my opinion, kind of like a violation of the Convention of Human Rights. :smile: I would propose something like AccessDeniedException
or AccessForbiddenException
. However, if you absolutely want to stick to InsufficientRightsException
, I can accept that.
In GitLab by @11712616 on Oct 10, 2021, 14:19
Commented on server/src/main/java/com/witness/server/exception/ServerException.java line 8
:thumbsup:
In GitLab by @11712616 on Oct 10, 2021, 14:19
Commented on server/src/main/resources/banner.txt line 1
:clap:
In GitLab by @11775820 on Oct 10, 2021, 14:41
Commented on server/src/main/java/com/witness/server/entity/User.java line 79
Yes, for @Entity
classes this is highly discouraged because it inflicts "serious performance issues" (don't remember the exact wording from the docs). If you were to change it, you'd get to see this warning.
In GitLab by @11775820 on Oct 10, 2021, 14:41
Commented on server/src/main/java/com/witness/server/enumeration/ServerError.java line 57
The fields here catch all possible errors that may come from Firebase as they are copied from Firebase's AuthErrorCode
enum, in order to work with the getFromFirebaseErrorCode
method. I included them so that, on the client side, we can create suitable error messages for these cases. If you really don't want to include them, we can remove them - the method would then return the fallback. I honestly prefer the current variant, but we can also go the way I just described. Your choice.
In GitLab by @11775820 on Oct 10, 2021, 14:41
Commented on server/src/main/java/com/witness/server/exception/DataAccessException.java line 11
The benefit I saw in doing it like this is not for the "public view", but for the "interface view". This way, I am able to more accurately describe what error state happens when and by which exception it is caused. This means I don't have to write "if X happens or Y happens or Z happens or...",but I can split it into the different exception types and error causes.
So it was just to make it easier for users of the services/service interfaces. That also makes it possible for them to catch specifically only those types of errors and propagate the more general exception to the other scope. And in my opinion, that's a neat thing to offer.
However, I agree that is technically a bit redundant. If you are so kind to check if we somewhere use the "feature" from above (only catch subtype, propagate supertype) and it turns out that we don't actually have it in use, I may as well throw the subtypes away.
In GitLab by @11775820 on Oct 10, 2021, 14:41
Commented on server/src/main/java/com/witness/server/exception/InsufficientRightsException.java line 11
Will probably go with AccessDeniedException
.
In GitLab by @11775820 on Oct 10, 2021, 14:41
Commented on server/src/main/java/com/witness/server/exception/ServerException.java line 8
"for to" -> "to"
In GitLab by @11712616 on Oct 10, 2021, 17:15
Commented on server/src/main/java/com/witness/server/enumeration/ServerError.java line 57
Okay, then leave it as is.
In GitLab by @11712616 on Oct 10, 2021, 17:15
Commented on server/src/main/java/com/witness/server/exception/DataAccessException.java line 11
If I am not mistaken, a DataAccessException
is only thrown in two places; once after catching a FirebaseAuthException
and once in the checkConsistency
method if the emails don't match.
In GitLab by @11775820 on Oct 10, 2021, 19:08
Commented on server/src/main/java/com/witness/server/exception/InsufficientRightsException.java line 11
30fe1964b6e2837b41e9a6bf8fef35bed609b713
In GitLab by @11775820 on Oct 10, 2021, 19:08
Commented on server/src/main/java/com/witness/server/exception/ServerException.java line 8
9c358d787b423fdf46bfdc6976d82df7d409a51e
In GitLab by @11775820 on Oct 10, 2021, 19:08
Commented on server/src/main/java/com/witness/server/exception/DataAccessException.java line 11
To be honest, after thinking about it, I would like to keep it as is. For example, have a look at the throws
clauses in the JavaDocs of UserSerivce#createUser
:
I actually do not want to lose the ability do differentiate between those types of errors and give information specifically targeted to them. If the API consumer does not care, they can just catch the super type DataAccessException
. But as the provider of the API, from a design point of view, I do see benefit in differentiating between those causes.
Do you see any potential drawbacks?
I have added class docs to the supertype and fixed typos in the commit 025e54255c00c70f15d58b2d695a3d289df1621b
In GitLab by @11775820 on Oct 10, 2021, 19:09
Commented on server/src/main/java/com/witness/server/exception/InsufficientRightsException.java line 11
changed this line in version 3 of the diff
In GitLab by @11775820 on Oct 10, 2021, 19:09
added 3 commits
In GitLab by @11775820 on Oct 10, 2021, 19:13
added 1 commit
In GitLab by @11712616 on Oct 10, 2021, 19:15
Commented on server/src/main/java/com/witness/server/exception/DataAccessException.java line 11
Keeping it as is is fine with me.
In GitLab by @11712616 on Oct 10, 2021, 19:18
approved this merge request
In GitLab by @11775820 on Oct 10, 2021, 19:20
resolved all threads
In GitLab by @11775820 on Oct 10, 2021, 19:25
added 9 commits
In GitLab by @11775820 on Oct 10, 2021, 19:27
mentioned in commit a0c3b0b791262cf2643ffd99f0f5093951ef0b73
In GitLab by @11775820 on Oct 10, 2021, 01:59
Merges 35-user-management -> develop
Closes #35.