FINERACT-2391: check for AppUser type before casting Authentication Principal in getCurrentAuditor

[nick9822]

Description

Now checking for AppUser type before casting Authentication Principal to avoid java.lang.ClassCastException in getCurrentAuditor.

Ignore if these details are present on the associated Apache Fineract JIRA ticket.

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

• Write the commit message as per https://github.com/apache/fineract/#pull-requests
• Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
• Create/update unit or integration tests for verifying the changes made.
• Follow coding conventions at https://cwiki.apache.org/confluence/display/FINERACT/Coding+Conventions.
• Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
• Submission is not a "code dump". (Large changes can be made "in repository" via a branch. Ask on the developer mailing list for guidance, if required.)

FYI our guidelines for code reviews are at https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide.

[adamsaghy]

I dont like this... from audit point of view, falling back to super user in this case is incorrect.

[galovics]

I mean this makes sense to me since in case the principal is not an AppUser, it'll eventually just throw an exception in the line below when casting.

If you say we shouldn't rely on the superuser when the principal is not an appuser, but rather handle it gracefully with the proper exception, that makes sense to me too.

[adamsaghy]

At this point, I’m not even comfortable with the existing logic that falls back to the superuser under any circumstances, but this might not be the right moment to fix everything.
Back to the main issue: the (now deprecated) self-service module allows anyone to perform operations during “self-registration,” and in those cases, all audit entries are recorded under the superuser account.
In the future, if for any reason the authentication principal becomes something other than an AppUser, Fineract would effectively use the “system” user for all audit entries, which, in my view, is incorrect behaviour. I would rather introduce a new AppUser (selfService) and that to be used for any of these operations instead.

[nick9822]

I think in two cases the principal won't be an AppUser, the public non-auth endpoints (self-service in this case) or any scheduler/worker related cases where chances are principal being empty or a string anonymousUser. I feel it's better to fallback on system user instead of admin user. I see there's a already a TODO comment on line#50 which happens to be the same.

[adamsaghy]

I will allow this in for now... but i dont think this falling back to "mifos" / "system" user is correct approach, but it's out of scope of this bug ticket.

[adamsaghy]

I dont like this... from audit point of view, falling back to super user in this case is incorrect.