Hi, Nice to hear that your experience of building your config/admin app has gone well.
With respect to the custom Javascript SPA/frontend, I think what I would say is that you should keep the login process for the SPA completely separate from that of the Wicket viewer. Trying to reuse the Wicket stuff is likely to lead into problems. To give you a flavour of what I mean, with the Wicket viewer we have to co-ordinate three different frameworks - Wicket, Shiro and Isis itself - so that they have a shared/consistent view of the current user. With Shiro there is SecuityUtils.getSubject() ... which reads a thread-local; with Wicket there is AuthenticatedWebSessionForIsis,get() which returns Isis' subclass of the Wicket AuthenticatedWebSession class ... again, another thread-local. There's also the HttpSession that's used by Wicket . With the Restful Objects viewer (REST API) on the other hand, there is deliberately no security specified. Moreover there is no usage of HttpSession, to make it potentially more scaleable. The web.xml generated by the archetypes sets up some filters - the ShiroFilter and also the IsisSessionFilterForRestfulObjects - but you can tweak these however you want. I believe that others in the community have got oAuth(2?) working, and we also have plans to integrate with keycloak in the future which I think will improve matters; at any rate, the mixed process that you are trying almost certainly isn't the way to go. HTH Dan On Sun, 22 Oct 2017 at 19:40 A. Richter <haskell...@yahoo.de.invalid> wrote: > Hello ISIS Team, > > we have developed a complex ISIS application using the Wicket Viewer, > Shiro and the ISIS Security Module. > The Wicket UI will be used for configuration and administration. Which now > works really well and was a lot of fun! > > For the normal user we are developing a Javascript frontend to display > user group specific dashboards with complex charts (D3/Snap.svg/JQuery/…) > using some data from ISIS Restful Object Viewer. The frontend user are > registered with specific roles in ISIS Security Module. > > We have configured shiro to protect the javascript under the path /app/** > in the following way: > > > [main] > .... > shiro.loginUrl = /wicket/signin > .... > [urls] > /app/** = authc > > Now when a user will access /app/index.html for the first time, he will be > redirected to the /wicket/signin page. > After the successful login he should be redirected to /app/index.html, > which is not happening. > > The standard Shrio login page is redirecting to the original requested > url/path after successful login. > > See [1]: > > "Based on this line of config, the authc filter is now smart enough to > know that if the current Subject is not authenticated when accessing > /account, it will automatically redirect the Subject to the /login.jsp > page. After successful login, it will then automatically redirect the user > back to the page they were trying to access (/account). Convenient!" > > How can we achieve this with ISIS or are there better ways of doing a > mixed login process? > > Thanks in advance and regards, > A. Richter > > > [1] https://shiro.apache.org/webapp-tutorial.html (Step 5b)
