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. 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 On Thu, May 24, 2018 at 3:00 PM, Isaac Kamga <isaac.ka...@mifos.org> 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 <my...@apache.org> wrote: > >> Hey Isaac, >> >> On Tue, May 1, 2018 at 11:17 AM, Isaac Kamga <isaac.ka...@mifos.org> >> 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 >>
