On Thu, Sep 16, 2010 at 6:53 PM, zooxmusic <[email protected]> wrote:
> I have a Swing desktop and a Spring remoting server like your examples. I
> looked at the webstart client and the spring server and feel I pretty much
> got the basic but....
> I'm not really sure why you guys made this example starting off with a jsp
> based log in and THEN switching to a desktop application. From my experience
> if your writing a desktop app, your writing a desktop app and not switching
> between web and desktop just to log in/out. I hope there is a nice clean way
> to do this but given the fact that you did the example this way scares me a
> little.

Oh, don't read too much into it. It's a demonstration of Shiro's
capabilities, not a demonstration of architecture. In the example, the
webapp is merely a delivery mechanism for the client app (you know,
it's easier to run a webstart app than install a desktop app). For
passing the session id, I don't think the mechanism used (dynamic jnlp
template) in the example is clunky at all but rather interesting and
also secure. Of course, it's a design decision that means you want the
same session id to be used for the lifetime of that application, which
probably isn't true in your case or even in most common cases.

> Can someone please give me a nice clean, non hokey way to use a swing app to
> login, return the sessionid, set it into the secureRemoteInvocationFactory
> and then be on my way?

The session management is entirely up to you. The possibilities are
too great and there are too many communication protocols for us to
suggest a particular way of doing it. If you are using http, consider
using cookies just the same way as a standard Java web application
does things. Want REST and you are allowed to simply use basic
authentication? Just pass the credentials in the headers. Just want to
return a temporary authentication token regardless of protocol? Create
a login service that returns a token on validated Shiro credentials. I
could have many other examples, but the issue has more to do with the
design of the authentication server you are connecting to than the
client. Consider the use cases for your service - what kind of clients
does it need to serve and then choose the simplest & most secure
option that covers all of those use cases.

Kalle

Reply via email to