Firstly, I want to say thanks again so much for all of the time/effort putting into answering my questions, I appreciate it very much.
Second, I want to apologize for not getting back to you in almost 2 weeks. Recently a family member became extremely ill, so I haven't been able to get to a computer much. I understand what you are saying, thanks a lot for clarifying it for me. One thing I am a little unsure about is if we config the web application, and Desktop-client application, to use the same setup/ini-file? Essentially I notice that the Shiiro Environment is already set up when calling my servlet from the desktop app, so wouldn't it be redundant to create a Factory using the ini file and setting up the security manager and such to use for the Desktop-Client when it's already set up through the web application part? It seems I can use things such as the FormAuthenticationFIlter and pass data to it and do request/response, but is that the correct way to handle this? Do I want to do something programatically, or am I going to be doing this another way? I'm a bit confused on how to proceed with doing this. I'm assuming I would work with the "web application" that is setup already? However how do I call that ini file programatically, to work with it? Is it the same as just using the factory setup as normal, or is there something special I should do here? I am also having trouble locating the ini file in order to create a factory instance myself. Normally I would use "classpath:(location)" but that doesn't seem to work with web app pathing. Or maybe I'm confused that I need to do something programatically, when I don't have to, but I would assume if I'm accessing something such as "FormAuthenticationFilter" that at I would need to work programatically with it's request/response handler to properly handle the Desktop-Application. Thanks a lot for your time I greatly appreciate it. ________________________________ From: scSynergy <[email protected]> Sent: Friday, October 14, 2016 2:55:11 AM To: [email protected] Subject: Re: How should we go about configuring a Desktop Client with Shiro in the Server? 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.
