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
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
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 <ronald.fei...@scsynergy.de>
Sent: Wednesday, October 12, 2016 3:24:59 AM
Subject: Re: How should we go about configuring a Desktop Client with Shiro in
All browsers handle sessions for you, so on the web client you need *not*
check sessions but instead just do form authentication:
https://shiro.apache.org/webapp-tutorial.html#step3 (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
View this message in context:
Sent from the Shiro User mailing list archive at Nabble.com.