I'm not sure why that last message sent when I was adjusting font size...
I guess these double emails continue .... >It is not the Subject, but the SecurityManager which is based on the machine. So, the result of subject.isAuthenticated() on one machine can differ from subject.isAuthenticated() on another machine even for the same instance of 'subject'. I don't have my code in front of me, but isn't the Subject created from the SecurtyManager? It doesn't seem, from what you said before, that we would use subject.isauthenticated() on the client in this instance though, what instances would we use it then? >What 'getSubject' returns is entirely dependent on your configured realms (which are managed by the SecurityManager) and whether they use a cache or not. So, if you send the subject from the client to the server, it might behave differently on the server than on the client - a subject might be authenticated on the client but not on the server because the states of the two SecurityManagers differ. well the basic subject seems to return username, password, host, I think IP, and a few other things, but I would assume we could create a one with a lot more information. Is there only one subject per machine for each security manager, or can we create multiple subjects per machine? I would assume that multiple instances of a Subject can be created since the server, in this case, would be the one to create Subjects, right? I would assume that we wouldn't need the security manager in the client if we are doing all of the security on the server. >Generally speaking the Shiro libraries should only be part of the server side application. The client should never use them if it is to authenticate against a server. The only exception to this rule I can think of is an offline capable Android app, but then you would need to synchronize (large) parts of your database between server and clients, anyway. So nothing of Shiro should be on the user machine, or nothing but the security manager as you mentioned above? Not sure how that fits. It makes sense that Shiro would just be on the server, but wasn't sure if it would be needed on the client at all. I'm confused by what you meant by "Based on the machine" I'm thinking that only one is created per machine, or did you mean that every instance is different per instance and the creation of Subjects is irrelevant? Thanks. One last thing about the session storage (if I go that route), it seems that EHCache does the comparison automatically, but how do we compare the sessions if we store it ourselves. I'm not sure if I saw an example of that. I assume we could send it as a request every time we refresh the page, which I assume is the same if we went stateless which would mean we would send the un/pw each time to authenticate? I do like the stateless idea a lot... Thanks so much for your time and help. ________________________________ From: scSynergy <[email protected]> Sent: Thursday, October 13, 2016 4:38:23 AM To: [email protected] Subject: Re: How should we go about configuring a Desktop Client with Shiro in the Server? It is not the Subject, but the SecurityManager which is based on the machine. So, the result of subject.isAuthenticated() on one machine can differ from subject.isAuthenticated() on another machine even for the same instance of 'subject'. What 'getSubject' returns is entirely dependent on your configured realms (which are managed by the SecurityManager) and whether they use a cache or not. So, if you send the subject from the client to the server, it might behave differently on the server than on the client - a subject might be authenticated on the client but not on the server because the states of the two SecurityManagers differ. Generally speaking the Shiro libraries should only be part of the server side application. The client should never use them if it is to authenticate against a server. The only exception to this rule I can think of is an offline capable Android app, but then you would need to synchronize (large) parts of your database between server and clients, anyway. -- 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-tp7581322p7581331.html Sent from the Shiro User mailing list archive at Nabble.com.
