Hi John, For multiple domains, either the wildcard domain cookie or passing a JSESSIONID parameter will work fine.
For the wildcard domain cookie, just set the '.foo.com' as the session ID cookie's domain. (securityManager.sessionManager.sessionIdCookie.domain = .foo.com) For the JSESSIONID solution, just pass it as a parameter (e.g. http://foo.com/whatever/something?JSESSIONID=blah) Shiro will recognize either approach. HTH! Best, Les On Tue, Feb 7, 2012 at 2:57 AM, John Moore <[email protected]> wrote: > On 06/02/12 22:33, Les Hazlewood wrote: >> >> Hi John, >> >> This will work - people have done this in the past. A major caveat >> however is to ensure that you're using HTTPS during all of the >> interactions/redirects to help protect against Man-in-the-Middle >> attack vectors. That is, it should be made as difficult as possible >> to intercept the session ID. >> >> > > Thanks for the warning. All traffic will be HTTPS, so that should be OK in > that respect. > > Having gone a little further down the line now, I am wondering how to get > around a little issue to do with cookies. If, as you say, people have done > this in the past, then I presume it is somehow possible to make work. Let's > say my product app is at 'product.mydomain.com', and my admin app is at > 'admin.mydomain.com'. They may or may not be on the same physical server (I > want to have flexibility in this respect). I have my session sharing > functionality set up nicely via Redis. What I want is for Single Sign On to > work between the admin and product apps - the user logs in to the admin app, > and is redirected to the product app, which they do not have to log in to > separately, through the magic of session sharing. The problem is that that > will only work if the browser submits the JSESSIONID cookie to the product > app - and because it's a different sub-domain, it's not doing so. Without > this JSESSIONID, the product app has nothing to look up to see if there is > an existing session. > > Now, I can see two theoretical ways round this conundrum. If I could somehow > ensure that the domain for the cookie is set to '.mydomain.com' instead of > 'admin.mydomain.com', then theoretically the browser should present the > cookie and hey presto! we'd be up and running. But I don't know if it's > possible to do this with Shiro. The second option would be to forgo cookies, > and instead pass the JSESSIONID as part of the query string in the redirect > URL. I would then need to cajole Shiro into using this request parameter > instead of looking for the JESSIONID cookie. This sounds like it should be > doable, but I don't know quite where I would need to do this. I will have > the powerful rewriting capabilities of an nginx reverse proxy server sitting > in front of both machines, which should give me some flexibility. In fact, > one option which leaps to mind with this would be to get nginx to check for > the presence of a JSESSIONID request parameter and if it exists, create a > matching cookie, which should work. But I'd still prefer to be able to do > this natively with Shiro if at all possible. > > John
