FINERACT-1577 TLS support in fully managed serverless environments

[IOhacker]

Description

TLS support in fully managed serverless environments it is required when Fineract is deployed in GCP Cloud Run, AWS App Runner/ECS and Azure Container Instances because the current properties in Fineract could cause 403 redirect.

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/api-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.

[IOhacker]

Rerun

[galovics]

I'd like to reiterate my comment from the other PR: #2285

The GCP related things shouldn't pollute the configurations everywhere but it should be extracted out (similarly what I suggested on the other PR).

Also, the property name fineract.security.on.gcp is definitely not going to fly with me because it doesn't represent the hierarchical naming. Probably for cloud native environments, it would make sense to start with the fineract.gcp group and then name this particular property fineract.gcp.security.enabled. This way we can capture all GCP related properties in a single group while keeping it very easy to extend.

What do you think Victor?

cc @vidakovic

[IOhacker]

I will take the suggestion just like the previous PR's comments. About property naming convention. What about adding "cloud" ? fineract.cloud.gcp... fineract.cloud.aws... fineract.cloud.azure... fineract.cloud.huawei... Then it could look like fineract.cloud.gcp.security.enabled El jue, 21 abr 2022 a las 3:36, Arnold Gálovics ***@***.***>) escribió:

…

I'd like to reiterate my comment from the other PR: #2285 <#2285> The GCP related things shouldn't pollute the configurations everywhere but it should be extracted out (similarly what I suggested on the other PR). Also, the property name fineract.security.on.gcp is definitely not going to fly with me because it doesn't represent the hierarchical naming. Probably for cloud native environments, it would make sense to start with the fineract.gcp group and then name this particular property fineract.gcp.security.enabled. This way we can capture all GCP related properties in a single group while keeping it very easy to extend. What do you think Victor? cc @vidakovic <https://github.com/vidakovic> — Reply to this email directly, view it on GitHub <#2286 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALD2ZAXMA3BHZ5L6DYMVDADVGEHSFANCNFSM5TTLHODQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[galovics]

Sure, adding the cloud prefix works too.

[vidakovic]

... we should see if there is already something standardized in the spring boot eco system...

[github-actions]

This pull request seems to be stale. Are you still planning to work on it? We will automatically close it in 30 days.

[galovics]

Closing as it's obsolete. Please reopen if you're planning to work on it.