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 <[email protected]> wrote: > Hey Isaac, > > On Tue, May 1, 2018 at 11:17 AM, Isaac Kamga <[email protected]> > 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 >
