Anyone successfully using Shiro 1.4 with Vaadin 10 to secure a web app?
I think, you’ll have to do some non-trivial stuff in order to get the “navigation” location from the RPC POST messages that Vaadin sends when using for example UI.getCurrent().navigate(""). I’ll explore this topic and publish something about it in the next weeks.
Thank you, Alejandro. For what it’s worth - excluding /VAADIN and /frontend from shiro’s protection services (set to anon) resulted in vaadin components being painted to the screen. But we would still get an “Invalid JSON response from server:” message in a div.v-system-error box. Only after setting /** to anon (very bad) does the JSON message go away. What are we missing? ps: Your book is arriving today, looking forward to reading it.
I just published a “component” on Vaadin Directory to integrate Vaadin 10 and Shiro. Check it out:
https://vaadin.com/directory/component/shiro-vaadin-integration
It wasn’t as simple as I initially thought, but it seems to work at least with the most simple cases. Please let me know if it works for you.
Basically, I implemented an AdviceFilter (VaadinNavigationRolesAuthorizationFilter) that inspects the body of POST requests in order to detect navigation RPCs and their locations. In order to do that I had to wrap the HTTP request object to allow reading its body information without interfering with Servlets. Also, I had to return a valid Java Script execute JSON response when the filter detected an unauthorized request in order to prevent the infamous “Invalid JSON response from server:” message and redirect to the login location instead.
Enjoy the [book]
(https://www.amazon.com/Data-Centric-Applications-Vaadin-Alejandro-Duarte/dp/1783288841) 
Book is great. Hope to see one for 10 too.
In testing of the new component we’ve found that we can get the desired behavior both with and without the new component and its filter - the critical change, as noticed in the example you’ve provided, being the shiro.ini’s assignement of the anon filter to “/” under the URLS section. Opening up the root prevented the JSON communication errors, while keeping the /** context path lock down.
ps: There is a video dated arround July 4 that suggests Vaadin 11 availability in two to three months. If indeed so, what are the differences calling for a new major version?
Richard, can you please confirm whether shiro-vaadin-integration worked for you or not?
Regarding the new Vaadin version scheme, we are now using to a “release train model”. Major releases come out every quarter. You can find more about this here: https://vaadin.com/blog/the-revaadin-platform
Alejandro, description of shiro-vaadin-integration provided a hint. Specificaly, we’ve set “/” to anon in shiro.ini. This new setting resolved the JSON errors. We did not put the shiro-vaadin-integration code nor the vaadin filter in use.