On Sun, May 10, 2020 at 4:41 PM Saransh Sharma <[email protected]> wrote:
> On Sun, 10 May 2020, 20:01 Giorgio Zoppi, <[email protected]> wrote: > >> >> El dom., 10 may. 2020 a las 14:22, Michael Vorburger (<[email protected]>) >> escribió: >> >>> Buongiorno (?) Giorgio! >>> >> >> Buongiorno Micheal, >> I have attached the report in the JIRA, i will take further investigation >> later against the old UI app. >> >>> >>> Cool! We're excited to see you explore >>> https://issues.apache.org/jira/browse/FINERACT-969. >>> >> >> >>> >>> >>>> As for the Parameters Query, the problem is the implementation itself. >>>> It will make sense to discuss a thinly layer for query separation. In the >>>> .NET world we have Dapper. https://github.com/StackExchange/Dapper used >>>> in StackOverflow. I dont know if there is a similar stuff in Java. >>>> >>> There are many, out there some are really cool. > >> >>> I'm not 100% sure what you mean, but I believe you may be making the >>> point that the use of an ORM (Object Relational Mapping) framework can help >>> prevent SQL Injection. I agree with this! FYI Fineract already uses one ( >>> https://openjpa.apache.org, but note >>> https://issues.apache.org/jira/browse/FINERACT-849 for potentially >>> possibly maybe switching). Fineract only uses ORM for write. Much read is >>> still direct SQL. >>> >>> It was related to ORM, but in more general to get all queries in a place >> and using Java Streams, the renderer will take care of doing paramtetric >> query for example: >> https://github.com/speedment/speedment . So you avoid that your student >> crafts queries >> > We kind of have to develop the framework approach rather then queries > written as usual. > >> concatenating strings but use just java streams . Does sense to open a >> jira ticket for that? >> > So the work that Manthan will be doing in https://issues.apache.org/jira/browse/FINERACT-854 hopefully will help to avoid that future Fineract developers craft queries by String concatenation, and address the possible SQL injection security vulnerability - in a pragmatic way that normally we are able to easily achieve really soon (next 2-3 weeks already, I'm hoping). What you are suggesting re. https://github.com/speedment/speedment looks "interesting" purely from a technical framework PoV, but probably isn't "required" for security (after FINERACT-854), but is more of a general new approach / framework? But you don't have to ask if you can open JIRA tickets, it's OK to just go ahead and create tickets. But it does of course raise the question of what the value of adding yet another framework and way of doing SQL queries in Fineract is... if you are interested in innovating in this space, nobody should be able to stop you, it's open source! If you asked me if I thought adding a new query framework was a top priority for the project, my answer probably would be some polite variation of "not so sure"... ;-) Hope this helps? Again, I think this isn't really related to pentesting in FINERACT-969. > I have started using Java Streams, most of the read is happening over the > sql native calls because of complex relationship defined. > > Speedmentn streams are nice. > >> >> >>> FYI we have a GSoC student who is going to work on >>> https://issues.apache.org/jira/browse/FINERACT-854 and >>> https://issues.apache.org/jira/browse/FINERACT-853. I would expect that >>> certain of the issues your work on FINERACT-969 will uncover will be fixed >>> by FINERACT-854. >>> >>> If I were you, I would not wait for that work to complete, but instead >>> go ahead, create JIRA bugs for everything you identify (best as sub-tasks >>> under FINERACT-962, perhaps?) - and then later help us verify that the >>> FINERACT-854 work actually fixed (some.. and which) of what you'll find. >>> Makes sense? >>> >> Yes, glad to help. >> >>> >>> >>>> I see the real meat is still old fineract, instead the fineract-cn is >>>> still work in progress. So i will install the old one. >>>> >>> >>> Contributions to both are obviously always very welcome... :_) >>> >> My idea about fineract-cn is that it doesn't make sense to craft in Java >> (i am sorry). It is too verbose for doing microservices, i would prefer >> another platform as .NET or Go. I don't see much work on cn yet. >> > Whole idea of the microservices is to allow any platform written in any > language. But at present this seems like a barrier. > > Thanks for your amazing work in fineract.dev, >> > Thank you for your feedback, appreciate it; glad you like it! it would be nice if some expert will prepare an appliance to be used in >> virtualbox. So it will speed up the testing and learning about fineract. >> > I think our current answer for speeding up the testing and learning about fineract locally now is to just use https://github.com/apache/fineract/#instructions-to-run-using-docker-and-docker-compose - are you aware of and perhaps already had a chance to try that? I'm personally not sure what value producing a VirtualBox image would add... In 2020 it's more about Containers than VMs? ;-) > Best Regards, >> Giorgio >> >
