I find a blemish when I write slice test in chapter 12.3.2

[ongiant]

1. Through creating the OrderControllerWebFluxTests, I noticed that ReactiveJwtDecoder MockBean was ultimately not utilized. The same appears to be true for JwtDecoder MockBean within the BookControllerMvcTests class in section 12.2.3. These injections seem to be superfluous and may need to be reevaluated.
2. In my opinion, the endpoint in OrderService would be more logically protected under the customer role, and there are a couple of reasons for this thought process: $\quad$ (1) Within the OrderControllerWebFluxTests class, the whenBookNotAvailableThenRejectOrder method utilizes webTestClient to send a mock request with a mock jwt holding the ROLE_customer authority. This test method would render moot if all requests were allowed to pass. $\quad$ (2) It seems unreasonable to me that a guest should have the ability to submit an order without the appropriate permissions.

Therefore, restricting this action could be beneficial for our application control.

[ThomasVitale]

@ongiant thanks for bringing this up!

1. You're right. The idea was to mock the JwtDecoder and ReactiveJwtDecoder beans in the integration tests because Spring Security would otherwise try to contact the real authorisation server configured in the properties as the Issuer URI to obtain the certificate needed to validate the signatures on received Access Tokens (JWTs). In slice tests like BookControllerMvcTests and OrderControllerWebFluxTests, it's not needed anymore (it used to, at some point, and I missed that it's not the case anymore, thank you for making me aware). I cleaned up the tests in the repo accordingly.
2. The Order Service application allows both customers and employees to order books without fine-grained permissions. In the simplified context of the example in the book, users can be registered in the system only with those two roles ("customer" and "role"). There isn't a "guest" role, so only those two types of users can actually order books. In a real-world scenario, it would definitely make sense to add role-based access control to Order Service. The primary reason for not doing that in this example was related to the practicalities around the book format and the educational goal of chapter 12: the topic was already covered for Catalog Service, so from an educational point of view it would have been too much doing it again in Order Service. It's already a big book :)

Thanks again for sharing your thoughts about this.