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.

Reply via email to