Session losing principals

[Stephen McCants <st...@hcs.us.com>]

Hello All,

I've got a strange Shiro problem I'm trying to track down where 
sometimes (race condition?) a session ends up containing the 
Authentication setting as true, but doesn't have a principal.

Here is what seems to be happening:

1) User accesses our system with a URL.
2) The URL contains a magic path that authenticates them and logs them 
in.  The Subject now is Authenticated and has a Principal.
3) The requested web page is sent to them.
4) The web page includes other pages (JavaScript, CSS, etc.).  The 
second request sometimes fails (accessing JavaScript) because the 
Subject is now Authenticated, but doesn't have a Principal, so we can't 
Authorize them.

With various break points, I can tell that the first subject is 
generated correctly and seems to be saved to the session correctly. The 
second subject is generated incorrectly because the session (same 
session ID, I checked) does not have a Principal (even though it does 
have an Authenticated value of true).

I've not had any luck figuring out what code is removing the Principal 
from the session, so I'm hoping for some pointers or debugging ideas.  
Setting a break point SessionDAO.upgdate(Session) has not proven helpful.

Any ideas?

Thanks!

Sincerely,
Stephen McCants

-- 
Stephen McCants
Senior Software Engineer
Healthcare Control Systems
1-877-877-8795 x116

Re: Session losing principals

[smm <st...@hcs.us.com>]

As a follow up, we found and fixed the problem.

We have two WAR files (so two Web Apps) that deploy inside the same Tomcat
instance and need "single sign on" between them.  That is, if you
authenticate to one, your session must work as authenticated for the other
(both use Shiro).

We built (for better or worse) our own code that sends updates between the
two Web Apps when something changed a session in one or the other.  The
communication is sent via a network broadcast, which meant both the sender
and the intended recipient would get the message.  We had a problem with the
sender processing its own message and getting confused and then discarding
the session information.

We fixed it by marking each message as being from a particular Web App and
that app would not process its own messages.

Hope that helps anyone else who might run into a similar problem.

--Stephen



--
View this message in context: http://shiro-user.582556.n2.nabble.com/Session-losing-principals-tp7580186p7580451.html
Sent from the Shiro User mailing list archive at Nabble.com.