Thanks for the information, I appreciate your time as does my friend.

That's interesting you don't need a JSP page, I thought that was needed in 
order to work with Shiro, but I guess that's just normal if you're going to 
make a JAva application with Shiro.

I believe his Desktop Client is JAvaFX, so there shouldn't be any issues, I 
would assume connecting.

So, essentially, everything gets done on the server, and only the responses 
should contain data that would be needed?  ie.., user.isauthenticated() we 
should just return true or false?

All we really need to pass is the session cookie or whatnot?  I think he is 
using EHCache, which I really have no clue how that works (I assume the same 
for him).

I was looking at EHChache last night and it seems like it's something I should 
read up on to understand how they store.  Shiro Web Sessions seem to handle 
themselves, but it seems that Desktop sessions require more work.

Essentially the application is divided into 2 parts.  1 Part is a desktop 
portion that is for admins to manage users and  upload information to the 
server.  The other part, the web portion, is designed to allow users to use 
that information.

I have been looking at the terms "Web Service" and "REST" but not really sure 
what they fully encompass, or if there is something special needed for them to 
be called a "Web Service" or "REST" but it seems that if you call code on the 
server to run some CRUD or other operation that itself is a Web Service?

The functionality of both the Desktop and the Server have been implemented, but 
Shiro has not been really implemented properly on the client, which is what 
they are trying to fix now, not sure what aspect would change the answer to 
solving this, though.

Overall, it seems that we should NOT have anything related to Shiro on the 
Client, and everything should be sent via HTTP to the server for verification.  
Now, do we just send the Session each time, or should we send the Login Token 
every time to verify?  I guess it doesn't really matter in the end as long as 
verification is present?  I know some people send the host information to the 
server to verify IP and such as well.  I guess we are just confused about the 
EHCache and how we verify the session with the Cache...  To me it sounds like 
sending the user token would be best, because you could prevent yourself from 
Session Poisoning/Session-hijacking, but that could also be said if their 
Username/Password was also stolen, but that's harder IMO.

Thanks a lot for helping us, I appreciate your time 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