Sorry for the double email, but hit reply too fast.  I was looking at your 
comment about "not sending" the Subject, but isn't the Subject created based on 
the user's machine?  It seems that when you get the security info and then 
getSubject that it will get a Subject fo the current machine.  Is there some 
parameter that would change this, or does a call to "getSubject" return a new 
subject each time?  Why would it be bad to send the Subject data to the client, 
since it's really just their information, or anon if they aren't logged in?

Thanks for the help, appreciate it scSynergy.

From: scSynergy <>
Sent: Wednesday, October 12, 2016 3:24:59 AM
Subject: Re: How should we go about configuring a Desktop Client with Shiro in 
the Server?

All browsers handle sessions for you, so on the web client you need *not*
check sessions but instead just do form authentication: (you need not use a JSP
page, any POST operation that results in the same HTTP request will work)
And then the browser will handle everything from there.

For the desktop client it depends very strongly on which technologies and
frameworks you use to decide how best to handle everything. Just do *not*
have the desktop client connect directly to your database and handle all the
business logic itself. Especially, what you should *not* do is pass the
SecurityManager or Subject to your clients. Instead keep all business logic
on the server and have the clients just display data and offer buttons and
such which trigger methods to run on the server.

Assuming that the desktop client and the web client offer the same
functionality I suggest you create REST services to create users and such
and then simply call those REST methods from within your desktop client and
web client alike.

Depending on whether the desktop client and web client have already been
implemented or not and which frameworks you use this may not be the best
option, though.

View this message in context:
Sent from the Shiro User mailing list archive at

Reply via email to