OSDir


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

Re: Apache Fineract CN API Documentation


Hi Myrle,

Thanks for your prompt reply.

On Sat, May 26, 2018 at 11:59 AM, Myrle Krantz <myrle@xxxxxxxxxx> wrote:

> Hey Isaac,
>
> There is an artifact test in anubis for acquiring access tokens for
> test.  The tokens for test give permissions to every endpoint in the
> service under test.  In a real environment, the tokens would be
> acquired from the identity environment and would have a much more
> limited set of permissions depending on the role assigned to the user
> being logged in.  Assuming you use anubis.test correctly, you don't
> actually need to validate the token before passing it in, but if
> you're having failures, it makes sense to do so as an aid in debugging
> the problem.


> The Spring Security filter is complex, and requires a deep
> understanding of spring security.  But I believe you can accomplish
> this task without understanding Spring Security.  If you want a better
> understanding of it though, check out this document:
> https://spring.io/guides/topicals/spring-security-architecture/
>
> Can you please push your code somewhere that I can look at it?  It
> would make it much easier to help you.  Two possibilities:
> * push it to your public github repository
> * create a branch in the fineract repos and push it there.
>

I've pushed changes to the *PoCFromIsaac* branch of fineract-cn-customer
<https://github.com/Izakey/fineract-cn-customer/tree/PocFromIsaac>  for
review.


> Currently my guess is that you are setting the token in the token
> header, but not setting the user or the tenant.  But without the code
> to look at this is very difficult to determine.
>
> Best Regards,
> Myrle
>

At Your Service,
Isaac Kamga.


>
> On Thu, May 24, 2018 at 3:00 PM, 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
> >>
>