The original developer (Lez Hazelwood) went with what he knew best, which was the Spring Framework which uses JSP pages as far as I know for web development. But as long as the resulting HTTP request is the same it does not matter whether that request was generated by JSP, naked HTML5, node.js, Python or whatnot.
Yes everything gets done on the server and the responses should only contain data that is to be displayed /updated on the client. No data should be returned by the server if the calling request fails to pass authentication. So, you would not check whether user.isAuthenticated() but instead fire a request to the server to load all users to display them in a list on the client. You would need to do a login on the first request and then resend the session cookie for subsequent calls to the server. If the request fails to pass authentication the client would have to react appropriately, e. g. by requesting the user to login (again after session has expired). Alternatively, you could make all calls to the server stateless by configuring Shiro to not create sessions on successful authentications: [urls] /login.xhtml = ssl[8443], user, authc /logout = logout # the next line is needed to retrieve jsf resources from jar library /javax.faces.resource/** = ssl[8443], anon /rest/** = *noSessionCreation*, ssl[8443], authcBasic /SoapService/** = *noSessionCreation*, ssl[8443], authcBasic /** = ssl[8443], user, authc "Web Service" generally means "pull data from server via the HTTP protocol" and it can be done by either SOAP (which I would only recommend if you need transactions) or REST (plain HTTP GET, PUT, POST, DELETE). With both SOAP and REST you can use either session cookies or not, depending on what you or your framework(s) prefer. If you decide not to use session cookies you would have to send username and password on each request to pass authentication. Do not send the login token as that is created form the username and password from the request on the server during the authentication process. I do not think EhCache is the proper tool here as it does not work on distributed machines without an added layer for synchronization between client and server and it completely bypasses HTTP and generally all Shiro authentication mechanisms and instead stores and manipulates Shiro sessions directly. We use EhCache to share Shiro's session cache for single sign on between independent Java applications on the *same* server (independent war files) - user logs in to one application and is automatically logged in to the other applications, too. Addressing your concerns about session hijacking / poisoning: that can happen, too, when using EhCache and a synchronization layer. A friendly tip on this behalf: It is generally considered impossible for a single person or small group to pinpoint and solve all security issues introduced by modern day applications. Instead one should use frameworks and tools which are in wide-spread use and have been well tested over time to address security issues. Using HTTP gives you the option to use TLS and a secure web framework to harden your communication between client and server - these tasks are generally well understood and you can find tons of information on how to achieve this (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project). How to secure EhCache and its underlying synchronization layer in contrast is a task you would have to find out for yourselves. -- View this message in context: http://shiro-user.582556.n2.nabble.com/How-should-we-go-about-configuring-a-Desktop-Client-with-Shiro-in-the-Server-tp7581322p7581330.html Sent from the Shiro User mailing list archive at Nabble.com.
