osdir.com

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

Re: Apache Fineract CN API Documentation


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
>