Jerry.
On 12/27/23 02:13, Jerry Malcolm wrote:
I implemented the filter as you suggested. But I guess I'm going to
need some education on sessions. Down in a user profile web page I have
a button to "Impersonate".
I'm with you so far.
I create the GenericPrincipal object and
store it in the session. I've checked several times, and every time I
come back to that code, the attribute is set in the session object.
Good. When you do that, do you remove the "real" user's GenericPrincipal
object from the session? Or are they both in there?
Remember that if Tomcat is going to enforce your authentication and
authorization constraints, your Filter will run after that, and Tomcat
and your application will disagree over which user is currently logged-in.
But when I put breakpoint in my new Filter object and look in the
session, no attribute. It's a different session object from what I
can tell.
That's weird.
When you say "every time I come back to that code, the attribute is set
in the session" ... what code are you taking about?
I
really thought I understood session objects. I thought there was only
one session object throughout the processing of a servlet.
Yes, if s/servlet/request/.
But I'm obviously missing something in the flows. Why is there a
different session object in the filter than in the main body of the
servlet? I did the getSession(false) as you suggested. The session
object is not null. It just doesn't have the attribute set. Yet if
I hit the Impersonate button again and hit the breakpoint, the
GenericPrincipal attribute is sitting in the session just as I placed
it earlier.
If the difference between when Tomcat evaluates e.g. user-roles versus
when your application does won't explain what's happening, we might need
to see some code.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
