[jira] [Commented] (FINERACT-1296) Needs to add Liveness & Readiness Probes for fineract server deployment
[ https://issues.apache.org/jira/browse/FINERACT-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292616#comment-17292616 ] Aleksandar Vidakovic commented on FINERACT-1296: [~BLasan] great (y) > Needs to add Liveness & Readiness Probes for fineract server deployment > --- > > Key: FINERACT-1296 > URL: https://issues.apache.org/jira/browse/FINERACT-1296 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Benura Abeywardena >Assignee: Benura Abeywardena >Priority: Minor > Fix For: 1.5.0 > > > It's better to add liveliness & readiness probes for fineract container in > order to avoid manual restarting of a container if it gets failed and to > determine when the container will be available for accepting traffic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1296) Needs to add Liveness & Readiness Probes for fineract server deployment
[ https://issues.apache.org/jira/browse/FINERACT-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292610#comment-17292610 ] Benura Abeywardena commented on FINERACT-1296: -- [~aleks] I'll make a PR for this today :) > Needs to add Liveness & Readiness Probes for fineract server deployment > --- > > Key: FINERACT-1296 > URL: https://issues.apache.org/jira/browse/FINERACT-1296 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Benura Abeywardena >Assignee: Benura Abeywardena >Priority: Minor > Fix For: 1.5.0 > > > It's better to add liveliness & readiness probes for fineract container in > order to avoid manual restarting of a container if it gets failed and to > determine when the container will be available for accepting traffic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1296) Needs to add Liveness & Readiness Probes for fineract server deployment
[
https://issues.apache.org/jira/browse/FINERACT-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292603#comment-17292603
]
Aleksandar Vidakovic commented on FINERACT-1296:
[~BLasan] alright, I'll keep it open. If someone wants to implement this: I've
looked up what's needed to get this in place... just below properties are
needed...
{quote}{{management.endpoint.health.probes.enabled=true}}
{{management.health.livenessState.enabled=true}}
{{management.health.readinessState.enabled=true}}
{quote}
{{Would be great if someone could create a PR for this (not really a big
change), otherwise we move it to the next release.}}
> Needs to add Liveness & Readiness Probes for fineract server deployment
> ---
>
> Key: FINERACT-1296
> URL: https://issues.apache.org/jira/browse/FINERACT-1296
> Project: Apache Fineract
> Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Benura Abeywardena
>Assignee: Benura Abeywardena
>Priority: Minor
> Fix For: 1.5.0
>
>
> It's better to add liveliness & readiness probes for fineract container in
> order to avoid manual restarting of a container if it gets failed and to
> determine when the container will be available for accepting traffic
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FINERACT-1070) Email Service Configurations defaults to port 25 irrespective of Port number specified
[ https://issues.apache.org/jira/browse/FINERACT-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292600#comment-17292600 ] Aleksandar Vidakovic commented on FINERACT-1070: [~BLasan] great... looks like this is pretty much finished and just needs approval. Thanks again! > Email Service Configurations defaults to port 25 irrespective of Port number > specified > -- > > Key: FINERACT-1070 > URL: https://issues.apache.org/jira/browse/FINERACT-1070 > Project: Apache Fineract > Issue Type: Bug > Components: User Management >Affects Versions: 1.4.0 >Reporter: Francis Guchie >Assignee: Benura Abeywardena >Priority: Critical > Fix For: 1.5.0 > > Attachments: email Service Configurations.png, > image-2020-10-15-11-17-57-324.png, image-2020-12-02-11-56-01-572.png, > image-2020-12-12-17-36-26-558.png, image-2021-02-06-00-17-36-048.png > > > Even if use sets the following, MifosX will not send emails > 1- Configure the server on which mifos is installed to be able to send Emails > - One can do this by installing sSMTP on the server and testing email sending > on the command line > 2- if using a gmail address only ports 465 and 587 will work because port 25 > is by default disabled on google servers This includes very many other VPS / > Mail servers > 3- Configure the port under the Email External Services Configuration > one will still get the error below > 03-Jul-2020 19:59:41.251 SEVERE [https-jsse-nio-443-exec-18] > com.sun.jersey.spi.container.ContainerResponse.mapMappableContainerException > The RuntimeException could not be mapped to a response, re-throwing to the > HTTP container > > org.apache.fineract.infrastructure.core.service.PlatformEmailSendException: > org.apache.commons.mail.EmailException: > Sending the email to the following server failed : smtp.gmail.com:25 > at > org.apache.fineract.infrastructure.core.service.GmailBackedPlatformEmailService.sendDefinedEmail(GmailBackedPlatformEmailService.java:81) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-1012) Spring Security OAuth 2.x to Spring Security 5.2.x
[
https://issues.apache.org/jira/browse/FINERACT-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic updated FINERACT-1012:
---
Fix Version/s: (was: 1.5.0)
1.6.0
> Spring Security OAuth 2.x to Spring Security 5.2.x
> --
>
> Key: FINERACT-1012
> URL: https://issues.apache.org/jira/browse/FINERACT-1012
> Project: Apache Fineract
> Issue Type: Bug
> Components: Security
>Affects Versions: 1.4.0
>Reporter: Michael Vorburger
>Assignee: Benura Abeywardena
>Priority: Critical
> Labels: beginner
> Fix For: 1.6.0
>
>
> The bump of spring-security-oauth2 from 2.3.6.RELEASE to 2.4.1.RELEASE in
> https://github.com/apache/fineract/pull/863 as part of FINERACT-963
> introduced usage of {{@Deprecated}} code, which we are trying to avoid (and
> which since FINERACT-959 we're intentionally making the build fail).
> I'm going to use a {{@SuppressWarnings("deprecation")}} to be able to do the
> upgrade anyway, because upgrading a security related library to its latest
> version seems like a sensible thing to do, but we really should remove the
> suppression and switch to using Spring's newer APIs.
> https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Migration-Guide
> affects {{UserDetailsApiResource}} and
> {{TwoFactorAuthenticationFilter.createUpdatedAuthentication()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FINERACT-1012) Spring Security OAuth 2.x to Spring Security 5.2.x
[
https://issues.apache.org/jira/browse/FINERACT-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292598#comment-17292598
]
Aleksandar Vidakovic commented on FINERACT-1012:
[~BLasan] thanks for the feedback... I'll label this issue for 1.6.0; maybe we
can do this in a broader context of moving Fineract entirely to Spring Boot
2.4.x.
> Spring Security OAuth 2.x to Spring Security 5.2.x
> --
>
> Key: FINERACT-1012
> URL: https://issues.apache.org/jira/browse/FINERACT-1012
> Project: Apache Fineract
> Issue Type: Bug
> Components: Security
>Affects Versions: 1.4.0
>Reporter: Michael Vorburger
>Assignee: Benura Abeywardena
>Priority: Critical
> Labels: beginner
> Fix For: 1.5.0
>
>
> The bump of spring-security-oauth2 from 2.3.6.RELEASE to 2.4.1.RELEASE in
> https://github.com/apache/fineract/pull/863 as part of FINERACT-963
> introduced usage of {{@Deprecated}} code, which we are trying to avoid (and
> which since FINERACT-959 we're intentionally making the build fail).
> I'm going to use a {{@SuppressWarnings("deprecation")}} to be able to do the
> upgrade anyway, because upgrading a security related library to its latest
> version seems like a sensible thing to do, but we really should remove the
> suppression and switch to using Spring's newer APIs.
> https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Migration-Guide
> affects {{UserDetailsApiResource}} and
> {{TwoFactorAuthenticationFilter.createUpdatedAuthentication()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FINERACT-1012) Spring Security OAuth 2.x to Spring Security 5.2.x
[
https://issues.apache.org/jira/browse/FINERACT-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292584#comment-17292584
]
Benura Abeywardena commented on FINERACT-1012:
--
[~aleks] Sorry sir, I didn't have a time to spend for this issue. If we are in
a hurry to release shall we move this issue for the next release sir?
> Spring Security OAuth 2.x to Spring Security 5.2.x
> --
>
> Key: FINERACT-1012
> URL: https://issues.apache.org/jira/browse/FINERACT-1012
> Project: Apache Fineract
> Issue Type: Bug
> Components: Security
>Affects Versions: 1.4.0
>Reporter: Michael Vorburger
>Assignee: Benura Abeywardena
>Priority: Critical
> Labels: beginner
> Fix For: 1.5.0
>
>
> The bump of spring-security-oauth2 from 2.3.6.RELEASE to 2.4.1.RELEASE in
> https://github.com/apache/fineract/pull/863 as part of FINERACT-963
> introduced usage of {{@Deprecated}} code, which we are trying to avoid (and
> which since FINERACT-959 we're intentionally making the build fail).
> I'm going to use a {{@SuppressWarnings("deprecation")}} to be able to do the
> upgrade anyway, because upgrading a security related library to its latest
> version seems like a sensible thing to do, but we really should remove the
> suppression and switch to using Spring's newer APIs.
> https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Migration-Guide
> affects {{UserDetailsApiResource}} and
> {{TwoFactorAuthenticationFilter.createUpdatedAuthentication()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FINERACT-1070) Email Service Configurations defaults to port 25 irrespective of Port number specified
[ https://issues.apache.org/jira/browse/FINERACT-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292581#comment-17292581 ] Benura Abeywardena commented on FINERACT-1070: -- [~aleks] I've already opened a PR for this. Check [https://github.com/apache/fineract/pull/1597] . Need a review from you and [~vorburger] sir > Email Service Configurations defaults to port 25 irrespective of Port number > specified > -- > > Key: FINERACT-1070 > URL: https://issues.apache.org/jira/browse/FINERACT-1070 > Project: Apache Fineract > Issue Type: Bug > Components: User Management >Affects Versions: 1.4.0 >Reporter: Francis Guchie >Assignee: Benura Abeywardena >Priority: Critical > Fix For: 1.5.0 > > Attachments: email Service Configurations.png, > image-2020-10-15-11-17-57-324.png, image-2020-12-02-11-56-01-572.png, > image-2020-12-12-17-36-26-558.png, image-2021-02-06-00-17-36-048.png > > > Even if use sets the following, MifosX will not send emails > 1- Configure the server on which mifos is installed to be able to send Emails > - One can do this by installing sSMTP on the server and testing email sending > on the command line > 2- if using a gmail address only ports 465 and 587 will work because port 25 > is by default disabled on google servers This includes very many other VPS / > Mail servers > 3- Configure the port under the Email External Services Configuration > one will still get the error below > 03-Jul-2020 19:59:41.251 SEVERE [https-jsse-nio-443-exec-18] > com.sun.jersey.spi.container.ContainerResponse.mapMappableContainerException > The RuntimeException could not be mapped to a response, re-throwing to the > HTTP container > > org.apache.fineract.infrastructure.core.service.PlatformEmailSendException: > org.apache.commons.mail.EmailException: > Sending the email to the following server failed : smtp.gmail.com:25 > at > org.apache.fineract.infrastructure.core.service.GmailBackedPlatformEmailService.sendDefinedEmail(GmailBackedPlatformEmailService.java:81) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1296) Needs to add Liveness & Readiness Probes for fineract server deployment
[ https://issues.apache.org/jira/browse/FINERACT-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292579#comment-17292579 ] Benura Abeywardena commented on FINERACT-1296: -- [~aleks] Sir, this is for k8s deployment. Not an essential one. But it's good if we could set up liveness and readiness probes for the fineract pod too. This can be fixed within 1 day. > Needs to add Liveness & Readiness Probes for fineract server deployment > --- > > Key: FINERACT-1296 > URL: https://issues.apache.org/jira/browse/FINERACT-1296 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Benura Abeywardena >Assignee: Benura Abeywardena >Priority: Minor > Fix For: 1.5.0 > > > It's better to add liveliness & readiness probes for fineract container in > order to avoid manual restarting of a container if it gets failed and to > determine when the container will be available for accepting traffic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-1296) Needs to add Liveness & Readiness Probes for fineract server deployment
[ https://issues.apache.org/jira/browse/FINERACT-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benura Abeywardena updated FINERACT-1296: - Summary: Needs to add Liveness & Readiness Probes for fineract server deployment (was: Needs to add Liveliness & Readiness Probes for fineract server deployment) > Needs to add Liveness & Readiness Probes for fineract server deployment > --- > > Key: FINERACT-1296 > URL: https://issues.apache.org/jira/browse/FINERACT-1296 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Benura Abeywardena >Assignee: Benura Abeywardena >Priority: Minor > Fix For: 1.5.0 > > > It's better to add liveliness & readiness probes for fineract container in > order to avoid manual restarting of a container if it gets failed and to > determine when the container will be available for accepting traffic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-982) Completely ditch use of Drizzle JDBC Driver after all
[ https://issues.apache.org/jira/browse/FINERACT-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292536#comment-17292536 ] Aleksandar Vidakovic commented on FINERACT-982: --- [~kaze] just saw your new comment... thanks again for pushing this forward :) > Completely ditch use of Drizzle JDBC Driver after all > - > > Key: FINERACT-982 > URL: https://issues.apache.org/jira/browse/FINERACT-982 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Assignee: Yemdjih Kaze Nasser >Priority: Blocker > Labels: scalability > Fix For: 1.5.0 > > > Fineract's use of the un-maintained Drizzle JDBC driver continues to cause > confusion and pains like FINERACT-980, and note e.g. the proposed removal of > the alternative MySQL JDBC driver in > [https://github.com/apache/fineract/pull/887.] > Some of the background to this is recorded e.g. in FINCN-26, FINERACT-761 and > LEGAL-462. > LEGAL-462 has clarified that the Fineract ZIP distribution must include > Drizzle and cannot distribute the MariaDB or MySQL JDBC clients. We CAN, and > currently (given the confusion in FINERACT-980 apparently do?!) use it for > tests. > What if to reduce variability we just removed that old Drizzle JDBC driver > after all? We could run our tests using (preferably) the very well maintained > MariaDB JDBC driver client (the actual DB server is a totally separate > discussion, see FINERACT-896). We would (have to) distribute the ZIP for > download without a JDBC driver, and just some documentation inviting users to > DL and add one. > But the exact situation about distributing in a Docker container image isn't > clear, to me... > FYI [~awasum], [~ptuomola], [~xurror] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-982) Completely ditch use of Drizzle JDBC Driver after all
[ https://issues.apache.org/jira/browse/FINERACT-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292535#comment-17292535 ] Aleksandar Vidakovic commented on FINERACT-982: --- [~kaze] the new mechanics in FINERACT-1177 are very simple: you just drop your driver jars let's say in a folder "libs" next to your fineract-provider.jar and provide an additional startup parameter "" that points to the folder with your JDBC driver jars. That way those drivers that are license incompatible can easily be added to the Fineract's classpath without manually extracting the Spring Boot uber-jar (as it was done before e. g. in the Docker image build). And then obviously you just have to change the driver class name and JDBC connection string in your configuration. So it should be fairly easy - once FINERACT-1177 gets accepted - to use any Mysql driver (Drizzle, MariaDB, Mysql Connector Java) as the standard driver in tests, because the driver is technically not part of the distribution (i. e. we are still compliant with the Apache License constraints). > Completely ditch use of Drizzle JDBC Driver after all > - > > Key: FINERACT-982 > URL: https://issues.apache.org/jira/browse/FINERACT-982 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Assignee: Yemdjih Kaze Nasser >Priority: Blocker > Labels: scalability > Fix For: 1.5.0 > > > Fineract's use of the un-maintained Drizzle JDBC driver continues to cause > confusion and pains like FINERACT-980, and note e.g. the proposed removal of > the alternative MySQL JDBC driver in > [https://github.com/apache/fineract/pull/887.] > Some of the background to this is recorded e.g. in FINCN-26, FINERACT-761 and > LEGAL-462. > LEGAL-462 has clarified that the Fineract ZIP distribution must include > Drizzle and cannot distribute the MariaDB or MySQL JDBC clients. We CAN, and > currently (given the confusion in FINERACT-980 apparently do?!) use it for > tests. > What if to reduce variability we just removed that old Drizzle JDBC driver > after all? We could run our tests using (preferably) the very well maintained > MariaDB JDBC driver client (the actual DB server is a totally separate > discussion, see FINERACT-896). We would (have to) distribute the ZIP for > download without a JDBC driver, and just some documentation inviting users to > DL and add one. > But the exact situation about distributing in a Docker container image isn't > clear, to me... > FYI [~awasum], [~ptuomola], [~xurror] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-982) Completely ditch use of Drizzle JDBC Driver after all
[ https://issues.apache.org/jira/browse/FINERACT-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292494#comment-17292494 ] Yemdjih Kaze Nasser commented on FINERACT-982: -- It's in progress now, PR has gone stale though. I'd like to give it another try. Expect a PR for this in a few hours. > Completely ditch use of Drizzle JDBC Driver after all > - > > Key: FINERACT-982 > URL: https://issues.apache.org/jira/browse/FINERACT-982 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Assignee: Yemdjih Kaze Nasser >Priority: Blocker > Labels: scalability > Fix For: 1.5.0 > > > Fineract's use of the un-maintained Drizzle JDBC driver continues to cause > confusion and pains like FINERACT-980, and note e.g. the proposed removal of > the alternative MySQL JDBC driver in > [https://github.com/apache/fineract/pull/887.] > Some of the background to this is recorded e.g. in FINCN-26, FINERACT-761 and > LEGAL-462. > LEGAL-462 has clarified that the Fineract ZIP distribution must include > Drizzle and cannot distribute the MariaDB or MySQL JDBC clients. We CAN, and > currently (given the confusion in FINERACT-980 apparently do?!) use it for > tests. > What if to reduce variability we just removed that old Drizzle JDBC driver > after all? We could run our tests using (preferably) the very well maintained > MariaDB JDBC driver client (the actual DB server is a totally separate > discussion, see FINERACT-896). We would (have to) distribute the ZIP for > download without a JDBC driver, and just some documentation inviting users to > DL and add one. > But the exact situation about distributing in a Docker container image isn't > clear, to me... > FYI [~awasum], [~ptuomola], [~xurror] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1012) Spring Security OAuth 2.x to Spring Security 5.2.x
[
https://issues.apache.org/jira/browse/FINERACT-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292493#comment-17292493
]
Aleksandar Vidakovic commented on FINERACT-1012:
[~BLasan] would you let me know what the current status of this issue is? Just
to know if we can include in the upcoming 1.5.0 release or if we need to move
it to the next one. Thanks.
> Spring Security OAuth 2.x to Spring Security 5.2.x
> --
>
> Key: FINERACT-1012
> URL: https://issues.apache.org/jira/browse/FINERACT-1012
> Project: Apache Fineract
> Issue Type: Bug
> Components: Security
>Affects Versions: 1.4.0
>Reporter: Michael Vorburger
>Assignee: Benura Abeywardena
>Priority: Critical
> Labels: beginner
> Fix For: 1.5.0
>
>
> The bump of spring-security-oauth2 from 2.3.6.RELEASE to 2.4.1.RELEASE in
> https://github.com/apache/fineract/pull/863 as part of FINERACT-963
> introduced usage of {{@Deprecated}} code, which we are trying to avoid (and
> which since FINERACT-959 we're intentionally making the build fail).
> I'm going to use a {{@SuppressWarnings("deprecation")}} to be able to do the
> upgrade anyway, because upgrading a security related library to its latest
> version seems like a sensible thing to do, but we really should remove the
> suppression and switch to using Spring's newer APIs.
> https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Migration-Guide
> affects {{UserDetailsApiResource}} and
> {{TwoFactorAuthenticationFilter.createUpdatedAuthentication()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FINERACT-854) Use prepared statements instead of string concatenated SQL everywhere
[
https://issues.apache.org/jira/browse/FINERACT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292492#comment-17292492
]
Aleksandar Vidakovic commented on FINERACT-854:
---
[~kaze] [~manthan] [~vorburger] any progress on this issue? What's the
current status of this?
> Use prepared statements instead of string concatenated SQL everywhere
> -
>
> Key: FINERACT-854
> URL: https://issues.apache.org/jira/browse/FINERACT-854
> Project: Apache Fineract
> Issue Type: Improvement
> Components: Security
>Reporter: Michael Vorburger
>Assignee: Manthan Surkar
>Priority: Major
> Labels: beginner, scalability, security, technical
> Fix For: 1.5.0
>
>
> The Fineract code base in many places creates SQL statements through String
> concatenation. This is prone to SQL injection. This is mitigated by the use
> of helpers utilities such as
> {{org.apache.fineract.infrastructure.core.api.ApiParameterHelper.sqlEncodeString(String)}}
> and
> {{org.apache.fineract.infrastructure.security.utils.SQLInjectionValidator.validateSQLInput(String)}}
> but I opine that those are workarounds... the better solution, both for
> security and likely also helping with performance (at least a little bit,
> knowing how much would require measuring it...), would be to use JDBC
> prepared statements with '?' placeholders and passing all raw arguments,
> instead of embedding them in the query String.
> FINERACT-808 root cause analysis brought this up, and I'm about to raise a PR
> for FINERACT-808 which makes a start; the goal of this issue is to use the
> new {{org.apache.fineract.infrastructure.security.utils.SQLBuilder}}
> everywhere, and eventually be able to get completely rid of
> {{ApiParameterHelper}} and {{SQLInjectionValidator}}.
> This issue should also include work to scan the code base for places where
> SQL Strings are concatenated without even using the existing helpers.
> FINERACT-853 could potentially help with that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FINERACT-1070) Email Service Configurations defaults to port 25 irrespective of Port number specified
[ https://issues.apache.org/jira/browse/FINERACT-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292489#comment-17292489 ] Aleksandar Vidakovic commented on FINERACT-1070: [~BLasan] [~francisguchie] [~al...@imperialcoop.com] could you tell me what the status of this issue is? Looks like we can close this (was it fixed or deferred to another release)? Please let me know to clean things up for release 1.5.0. > Email Service Configurations defaults to port 25 irrespective of Port number > specified > -- > > Key: FINERACT-1070 > URL: https://issues.apache.org/jira/browse/FINERACT-1070 > Project: Apache Fineract > Issue Type: Bug > Components: User Management >Affects Versions: 1.4.0 >Reporter: Francis Guchie >Assignee: Benura Abeywardena >Priority: Critical > Fix For: 1.5.0 > > Attachments: email Service Configurations.png, > image-2020-10-15-11-17-57-324.png, image-2020-12-02-11-56-01-572.png, > image-2020-12-12-17-36-26-558.png, image-2021-02-06-00-17-36-048.png > > > Even if use sets the following, MifosX will not send emails > 1- Configure the server on which mifos is installed to be able to send Emails > - One can do this by installing sSMTP on the server and testing email sending > on the command line > 2- if using a gmail address only ports 465 and 587 will work because port 25 > is by default disabled on google servers This includes very many other VPS / > Mail servers > 3- Configure the port under the Email External Services Configuration > one will still get the error below > 03-Jul-2020 19:59:41.251 SEVERE [https-jsse-nio-443-exec-18] > com.sun.jersey.spi.container.ContainerResponse.mapMappableContainerException > The RuntimeException could not be mapped to a response, re-throwing to the > HTTP container > > org.apache.fineract.infrastructure.core.service.PlatformEmailSendException: > org.apache.commons.mail.EmailException: > Sending the email to the following server failed : smtp.gmail.com:25 > at > org.apache.fineract.infrastructure.core.service.GmailBackedPlatformEmailService.sendDefinedEmail(GmailBackedPlatformEmailService.java:81) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-982) Completely ditch use of Drizzle JDBC Driver after all
[ https://issues.apache.org/jira/browse/FINERACT-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292487#comment-17292487 ] Yemdjih Kaze Nasser commented on FINERACT-982: -- If I'm not mistaken, the docker build from before allowed an option to use mysql-connector for a containerized run. I think the issue with using mysql/mariadb connector in dev environment like for running tests still persists. Unless I've failed to really understand how FINERACT-1177 works, I think this still persists to some extent. > Completely ditch use of Drizzle JDBC Driver after all > - > > Key: FINERACT-982 > URL: https://issues.apache.org/jira/browse/FINERACT-982 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Assignee: Yemdjih Kaze Nasser >Priority: Blocker > Labels: scalability > Fix For: 1.5.0 > > > Fineract's use of the un-maintained Drizzle JDBC driver continues to cause > confusion and pains like FINERACT-980, and note e.g. the proposed removal of > the alternative MySQL JDBC driver in > [https://github.com/apache/fineract/pull/887.] > Some of the background to this is recorded e.g. in FINCN-26, FINERACT-761 and > LEGAL-462. > LEGAL-462 has clarified that the Fineract ZIP distribution must include > Drizzle and cannot distribute the MariaDB or MySQL JDBC clients. We CAN, and > currently (given the confusion in FINERACT-980 apparently do?!) use it for > tests. > What if to reduce variability we just removed that old Drizzle JDBC driver > after all? We could run our tests using (preferably) the very well maintained > MariaDB JDBC driver client (the actual DB server is a totally separate > discussion, see FINERACT-896). We would (have to) distribute the ZIP for > download without a JDBC driver, and just some documentation inviting users to > DL and add one. > But the exact situation about distributing in a Docker container image isn't > clear, to me... > FYI [~awasum], [~ptuomola], [~xurror] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1095) Remove direct sqlSearch support from /clients and all other APIs [Security & Performance]
[
https://issues.apache.org/jira/browse/FINERACT-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292485#comment-17292485
]
Aleksandar Vidakovic commented on FINERACT-1095:
[~manthan] [~vorburger] is this still being worked on? I see that this was
already partially implemented... any status on what's left?
> Remove direct sqlSearch support from /clients and all other APIs [Security &
> Performance]
> -
>
> Key: FINERACT-1095
> URL: https://issues.apache.org/jira/browse/FINERACT-1095
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Michael Vorburger
>Assignee: Manthan Surkar
>Priority: Major
> Fix For: 1.5.0
>
>
> While code reviewing PRs from [~Manthan] such as
> [https://github.com/apache/fineract/pull/1171/files] and
> [https://github.com/apache/fineract/pull/1123/files] re. FINERACT-854, I've
> learnt about Fineract's support for an {{sqlSearch}} parameter on a number of
> its APIs, such as {{/clients}} (and others).
> According to
> [https://demo.fineract.dev/fineract-provider/api-docs/apiLive.htm] :
> {quote}_sqlSearch
> String optional
> Use an sql fragment valid for the underlying client schema to filter
> results. e.g. display_name like %K%
> {quote}
> [https://github.com/apache/fineract/search?p=2=sqlSearch_q=sqlSearch]
> shows all current occurrences. There are a number, but not THAT many either.
> (By far not every API supports this, only a handful.)
> This can be used e.g. like this:
> [https://demo.fineract.dev/fineract-provider/api/v1/clients?paged=true=c.account_no=3=default]
> To me, this is an egregious violation of "layering architecture". Basically,
> the REST API gives you direct SQL database access! You apparently have to
> know the exact name of not the SQL table but the alias used in the respective
> internally hard-coded query (note the use of {{c.}} in the example above, NOT
> {{m_client}}), and the internal SQL column name (note the use of
> {{account_no}}, NOT {{accountNo}}). There is no real documentation how to use
> this, and even if there were, in my tests I've noticed its fairly easy to
> provoke _500 Internal Server Errors_ when using {{sqlSearch}} with a slightly
> wrong syntax.
> From a security point of view, it's not quite as bad as it looks, because
> there is code with heuristics to "validate" the {{sqlSearch}} and prevent SQL
> Injections. But that could have holes (I don't want to know!), so... this
> still isn't great, at all, IMHO.
> From a performance point of view, permitting clients to run arbitrary queries
> isn't great either. You can't really reliable offer performance guarantees,
> or offer tuning with indices, if at the end of the day the wide open API just
> lets a client "query whatever they want" anyway.
> Use of {{sqlSearch}} by (public) API clients isn't that hard to find. I did
> some digging, and:
> * The new web-app UI doesn't use sqlSearch (or not yet), see
> [https://github.com/openMF/web-app/search?q=sqlSearch_q=sqlSearch]
> * The old community-app UI does use sqlSearch, see
> [https://github.com/openMF/community-app/search?p=1=sqlSearch_q=sqlSearch].
> But only in 2 very specific places, for Loans' {{l.loan_status_id in
> (100,200)}} and Clients' {{c.status_enum=100}}. This was apparently
> introduced by [~vishwasbabu] in
> [https://github.com/openMF/community-app/pull/1582|https://github.com/openMF/community-app/pull/1582/files]
> for [MIFOSX-2712.|https://mifosforge.jira.com/browse/MIFOSX-2712.] It's
> noteworthy that the Find on
> [https://cui.fineract.dev/.../clients|https://cui.fineract.dev/?baseApiUrl=https://demo.fineract.dev=default#/clients]
> does NOT use {{sqlSearch}} but the [/search
> API|https://demo.fineract.dev/fineract-provider/api-docs/apiLive.htm#search]
> * other repos on openMF, such as Mobile Apps & Co, don't realy seem to
> actively use {{sqlSearch}}, looking at
> [https://github.com/search?p=7=org%3AopenMF+sqlSearch=Code]
> Other than that, I don't know if anyone actively using {{sqlSearch}} would
> have any major objections to... just simply altogether removing this
> entirely? Folks may of course be using this in their own client UIs, but...
> they really shouldn't, this is a "bad" API. If you are missing a query
> facility, just contribute to the upstream project and raise a pull request to
> add whatever query option you are missing to whatever Fineract API (such as
> e.g. by status for Loans and Clients).
> Let's further discuss on the developer mailing list on thread "Use of
> sqlSearch argument in Groups/Clients List" if anyone wants to strongly defend
> {{sqlSearch}}. If not, let's just completely remove it. We do have to first
> replace the small current use in
[jira] [Commented] (FINERACT-1034) RSA Encryption
[ https://issues.apache.org/jira/browse/FINERACT-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292483#comment-17292483 ] Aleksandar Vidakovic commented on FINERACT-1034: [~fynmanoj] is this still being worked on? From what I understood in the description: I think this is covered by the fact that we always send data over HTTPS. Encrypting pieces of information inside of an encrypted channel (HTTPS) doesn't give yield "more security", because it's "twice encrypted". In the end what you are describing is a bit like OAuth access tokens (concerning the timeouts). Speaking from own experience in implementing such a feature: you'll see that once in production you'll probably need to relax the timeouts considerably, because the parties (clients) involved have out of tune system clocks. I used this approach with a REST API where the authentication was done with an API key that was encrypted with validity timeout. In the end I had to relax the timeouts in the range of minutes, because the integration partner was unable to tune his clocks. I'd suggest to close this issue if there's no further activity here. > RSA Encryption > -- > > Key: FINERACT-1034 > URL: https://issues.apache.org/jira/browse/FINERACT-1034 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Manoj >Assignee: Manoj >Priority: Minor > Fix For: 1.5.0 > > > Add RSA key generation API and decryption infra for requests that require > encryption from source such as biometric, authentication etc.. Also create a > self expiring keystore -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (FINERACT-1058) Add support for "limit" and "order by" query in SQLBuilder
[ https://issues.apache.org/jira/browse/FINERACT-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292478#comment-17292478 ] Aleksandar Vidakovic edited comment on FINERACT-1058 at 2/28/21, 7:01 PM: -- [~manthan] any progress on this one and/or is this still being worked on? Looks like this was already merged with [https://github.com/apache/fineract/pull/1123|https://github.com/apache/fineract/pull/1123.] ... can we close this issue then? was (Author: aleks): [~manthan] any progress on this one and/or is this still being worked on? > Add support for "limit" and "order by" query in SQLBuilder > --- > > Key: FINERACT-1058 > URL: https://issues.apache.org/jira/browse/FINERACT-1058 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Manthan Surkar >Assignee: Manthan Surkar >Priority: Major > Fix For: 1.5.0 > > Attachments: screenshot-1.png > > > This is in continuation of the work done by [~vorburger] in > https://github.com/apache/fineract/pull/725 > The SQL builder currently does not support limit and order by operation. We > can either keep the operations independent of SQLbuilder (which is certainly > not recommended imo) or add it as a part of it. > WDYT [~vorburger] [~awasum] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1058) Add support for "limit" and "order by" query in SQLBuilder
[ https://issues.apache.org/jira/browse/FINERACT-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292478#comment-17292478 ] Aleksandar Vidakovic commented on FINERACT-1058: [~manthan] any progress on this one and/or is this still being worked on? > Add support for "limit" and "order by" query in SQLBuilder > --- > > Key: FINERACT-1058 > URL: https://issues.apache.org/jira/browse/FINERACT-1058 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Manthan Surkar >Assignee: Manthan Surkar >Priority: Major > Fix For: 1.5.0 > > Attachments: screenshot-1.png > > > This is in continuation of the work done by [~vorburger] in > https://github.com/apache/fineract/pull/725 > The SQL builder currently does not support limit and order by operation. We > can either keep the operations independent of SQLbuilder (which is certainly > not recommended imo) or add it as a part of it. > WDYT [~vorburger] [~awasum] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1296) Needs to add Liveliness & Readiness Probes for fineract server deployment
[ https://issues.apache.org/jira/browse/FINERACT-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292477#comment-17292477 ] Aleksandar Vidakovic commented on FINERACT-1296: [~BLasan] is this issue still relevant? If I remember correctly you get this feature automatically by using Spring Cloud. I think there's nothing to do here for us (aka let's close it). > Needs to add Liveliness & Readiness Probes for fineract server deployment > - > > Key: FINERACT-1296 > URL: https://issues.apache.org/jira/browse/FINERACT-1296 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Benura Abeywardena >Assignee: Benura Abeywardena >Priority: Minor > Fix For: 1.5.0 > > > It's better to add liveliness & readiness probes for fineract container in > order to avoid manual restarting of a container if it gets failed and to > determine when the container will be available for accepting traffic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-982) Completely ditch use of Drizzle JDBC Driver after all
[ https://issues.apache.org/jira/browse/FINERACT-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292474#comment-17292474 ] Aleksandar Vidakovic commented on FINERACT-982: --- [~kaze] [~vorburger] can we close this issue now that FINERACT-1177 is done and pretty much addresses and solves this issue too? > Completely ditch use of Drizzle JDBC Driver after all > - > > Key: FINERACT-982 > URL: https://issues.apache.org/jira/browse/FINERACT-982 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Assignee: Yemdjih Kaze Nasser >Priority: Blocker > Labels: scalability > Fix For: 1.5.0 > > > Fineract's use of the un-maintained Drizzle JDBC driver continues to cause > confusion and pains like FINERACT-980, and note e.g. the proposed removal of > the alternative MySQL JDBC driver in > [https://github.com/apache/fineract/pull/887.] > Some of the background to this is recorded e.g. in FINCN-26, FINERACT-761 and > LEGAL-462. > LEGAL-462 has clarified that the Fineract ZIP distribution must include > Drizzle and cannot distribute the MariaDB or MySQL JDBC clients. We CAN, and > currently (given the confusion in FINERACT-980 apparently do?!) use it for > tests. > What if to reduce variability we just removed that old Drizzle JDBC driver > after all? We could run our tests using (preferably) the very well maintained > MariaDB JDBC driver client (the actual DB server is a totally separate > discussion, see FINERACT-896). We would (have to) distribute the ZIP for > download without a JDBC driver, and just some documentation inviting users to > DL and add one. > But the exact situation about distributing in a Docker container image isn't > clear, to me... > FYI [~awasum], [~ptuomola], [~xurror] -- This message was sent by Atlassian Jira (v8.3.4#803005)
