osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apache Fineract CN API Documentation


Isaac - This is a thread I am trying to follow.  Thank you for all the work
you're putting in, and to Myrle for being a mentor on this work.  Seems
like it is leading to something really important for the project.

I wonder if this <
https://cwiki.apache.org/confluence/display/FINERACT/Apache+Fineract+CN+API+Documentation
>
should or could be expanded to explain and document the API or if we should
have a separate API Documentation File.

At a requirements level, I'm trying to figure out how Mojaloop APIs and
Fineract-CN APIs would interact, perhaps as a model for how Fineract-CN and
other outside API driven systems will function together.  On the Mojaloop
project they have a 190 page documentation of the standard API starting
with some statements that I think may also be relevant to how the
Fineract-CN services architecture is set up.
https://github.com/mojaloop/mojaloop-specification/blob/master/API%20Definition%20v1.0.pdf


Specifically, I'm referring to section 3.1.1. .  Of those characteristics
mentioned, which apply to Fineract-CN? :

   - Fully Asychronous (esp for long running processes) :  my guess, seems
   likely yes on Fineract-CN - yes?
   - Decentralized (no central authority):  My current understanding is
   that Fineract-CN has dependencies but not centralization?
   - Service Oriented :  that seems like a given in Fineract-CN as it is
   also a micro-services arch.
   - Not fully stateless (some info required to be kept client and server
   side to complete fin tranx):  Hmm...
   - Client (side) decided common ID (complexity reduced by relying on
   client to initiate tranx calls):  Maybe not yet in our thinking ? contrary?

Similarly, there is a reference to how generic URI's are formed with a
given example:
scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]

and other things like max header size and so forth.

As I lack the skills to actually work on this code, I'm hoping I can
contribute at the level of conceptual understanding and requirements, and
perhaps add to the Documentation if I can understand what is actually going
on here.  If this is already documented, please send me there.

( Myrle - hope this is helpful, if not, let me know please.  )

Thanks,
- James


On Thu, May 24, 2018 at 6:00 AM Isaac Kamga <isaac.kamga@xxxxxxxxx> wrote:

> Hello Myrle,
>
> Trust that you're doing great.
>
> Following your recommendations, I intended solving the issue using a 3-step
> approach;
>
> 1. Obtain token
> 2. Validate token
> 3. Add token to MockMvc call as a header.
>
> However, I've been unable to get status different from 404 (Not Found) and
> 403 (Forbidden) in the MockMvc calls...so I think I'm getting at least one
> of the 3 steps above wrong.
>
> Regarding 1.), I used TenantApplicationSecurityTestRule's
> getPermissionToken() method to obtain some tokens based on Allowed
> operations (Read, Change and Delete) and they were each of the form
> "*Bearer
> eyJhbGciOiJSU....*". Which service actually generates tokens ?
> TenantAccessTokenSerializer
> in anubis ?
>
> Concerning 2.), The tokens I obtained failed the
> SystemSecurityEnvironment's isValidToken() method.  So how can we validate
> the obtained tokens ?
>
> Regarding 3.), I noticed that Spring MVC Test provides an interface called
> the RequestPostProcessor
> <
> https://github.com/spring-projects/spring-framework/blob/master/spring-test/src/main/java/org/springframework/test/web/servlet/request/RequestPostProcessor.java
> >
> which
> can be used to modify a request. I intend to use this to add a valid token
> to each MockMvc call. I wrote a method which modifies a request by
> adding a *header(ApiConstants.AUTHORIZATON_HEADER,
> myToken)* and then running each MockMvc call in the unit test with an
> object of the class holding this method.
>
> Also, you mentioned a Spring Security filter which filters requests to
> endpoints. Where exactly is this filter located ? I've been scouring anubis
> for it to no avail. I'm considering mocking the filter to permit specific
> tokens or calls go through.
>
> Your help will be greatly appreciated.
>
> At Your Service,
> Isaac Kamga.
>
> On Tue, May 1, 2018 at 11:41 AM, Myrle Krantz <myrle@xxxxxxxxxx> wrote:
>
> > Hey Isaac,
> >
> > On Tue, May 1, 2018 at 11:17 AM, Isaac Kamga <isaac.kamga@xxxxxxxxx>
> > wrote:
> > > Thanks for your very helpful feedback.
> >
> > You're very welcome.  Thank you for taking it so well.
> >
> > > Do we have to use a different approach ( possibly the documentation
> > module
> > > you earlier proposed ) for asynchronous calls (POST, PUT, DELETE ) from
> > > synchronous ones (GET) ? This can be done later but I wanted to know
> your
> > > thoughts on this.
> >
> > Fortunately we do not.  The asynchronous calls will return an
> > ACCEPTED, and the synchronous calls will return OK.  From the point of
> > view of the documentation, and of calling them, that's the only
> > difference.  The asynchronous calls can also return BAD REQUEST for
> > any invalid values which are fast to check (where the synchronous ones
> > will return BAD REQUEST for invalid values regardless of how easy they
> > are to check.)
> >
> > The documentation module is still an open question for me.  But not
> > because of asynchronous vs synchronous calls.
> >
> > > Thanks for shedding more light on how this works. When I saw how "easy"
> > it
> > > was to do API calls, I asked myself how one could get to intercept
> > > information such as the status of a response. Building a new test
> harness
> > > that works with mockmvc can be a daunting task. I hope I can count on
> > your
> > > help when I run into frustrations.
> >
> > I'll do what I can, but I don't know mockmvc.  I've never used it,
> > partly because of this problem.
> >
> > > So far, I created this document
> > > <https://cwiki.apache.org/confluence/display/FINERACT/Apache
> > +Fineract+CN+API+Documentation>
> > > to
> > > help developers generate the asciidoc files themselves from the unit
> > tests.
> > > Would you prefer that we put this in the repository's README file or
> > leave
> > > it on confluence ?
> >
> > Let's start off with it where it is, and see whether it works by
> > trying it out there.
> >
> > You're doing good,
> >
> > Best Regards,
> > Myrle
> >
>