[APOLOGIES IF PEOPLE ARE GETTING MULTIPLE POSTINGS - I'M NOT SEEING THEM]
Here's the message again:
9 posts
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
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/Redirect-to-different-app-tp7254157p7272710.html
Sent from the Shiro User mailing list archive at Nabble.com.
