The subject is a kind of proxy to the underlying SecurityManager meaning some
methods of Subject actually just trigger calls to the SecurityManager which
in turn triggers methods on the configured realms.

You would use subject.isAuthenticated() on the server's HTTP interface to
determine whether to proceed with server side code or return an HTTP 401.

Your subject only returns username and password because the realm(s) you use
creates a UsernamePasswordToken - other realms may create tokens which look
entirely different.

Let Shiro create the subjects for you from your realms - it is designed to
work that way, do not create subjects yourselves.

Nothing Shiro goes on the client.

"Based on the machine": The SecurityManager is created from your Shiro
environment which would most likely differ between client and server -
resulting in SecurityManagers which behave differently.

If you use Shiro the way it was designed it will compare the session on its
own without you having to do it yourselves - that way, you need not store
the sessions yourselves, either.

Just to be absolutely clear: We only configure the Shiro environment and the
Shiro realms and let Shiro handle everything else on its own. Then clients
request data or trigger business logic via HTTP requests - some using
sessions (browsers) others without sessions (Java, .NET, Python). None of
the clients does any authentication or authorization - they just pass
credentials on to the server to request data from the server and display the
data to the user; or they trigger business operations on that data via HTTP
requests to the server. *This architecture is what Shiro really caters to
and excels at.*



--
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-tp7581322p7581336.html
Sent from the Shiro User mailing list archive at Nabble.com.

Reply via email to