Jerry,
On 12/28/23 18:33, Jerry Malcolm wrote:
Chris,
On 12/28/2023 3:38 PM, Christopher Schultz wrote:
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?
>
Sorry... lost you on that one. I am just setting a custom > "GenericPrincipal"
attribute named "impersonatedPrincipal" in the
session when a user clicks the "Impersonate" button on the web page.
This answers my question. I was wondering if you do this:
session.setAttribute("user", impersonatedUser); // Replace
or this:
session.setAttribut("impersonatedUser", impersonatedUser);
And it seems you are doing the second one.
In my understanding, at this point I'm just 'telling' the session
that on subsequent requests in the custom filter, here's a principal
object that I want to insert.
As long as your code agrees with you :)
I also noted in your early example that you stored a
'User' class as the attribute in the session, not a GenericPrincipal. I
couldn't find a "User" class. So I just used GenericPrincipal, since
that was what I will insert in the request object in the filter.
We use User in our session, and essentially wrap it in a
GenericPrincipal when necessary. We are playing a lot of games, here, in
our code, so I apologize if we go down this road and it's a lot longer
than you had expected...
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.
>
I'm not removing the real principal from anything. Not sure how to do
that? in HttpSession? in HttpRequest? I assumed returning my new
GenericPrincipal in the RequestFacade would override any other code
asking for the principal.
It will... unless that code runs before your Filter has a chance to pull
the wool over the application's eyes. For example... Tomcat's
authentication and authorization code will run in a Valve, which runs
before all Filters.
How do I go about removing the real principal?
Let's save that for later ;)
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?
>
The filter's 'version' of the session doesn't have the
"impersonatedPrincipal" attribute set (it doesn't have any attributes
set). But after clicking Impersonate, hitting the breakpoint, and
watching the session attribute get set, I hit F5 to refresh the page.
The filter breakpoint again doesn't have the attribute. But if I click
"Impersonate" again and hit that breakpoint the "impersonatedPrincipal"
session attribute exists in the session.
Is the session identifier changing?
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.
Code:
Other than a loop that builds a Roles vector, these are the two lines
that create the session attribute when the "Impersonate" button is clicked.
GenericPrincipal newPrincipal = new GenericPrincipal( getUserName(),
getPassword(),
roles );
getCtrl().getRequest().getSession(false).setAttribute(
"impersonatedPrincipal", newPrincipal );
Hmm. What are Ctrl and Request that you are "getting"? Usually, both the
servlet and the Filter see objects passed to them directly in the
doFilter() and service()/doGet/doPost/whatever methods in the servlet.
And this is the filter:
PrintWriter out = response.getWriter();
HttpSession session =
((HttpServletRequest)request).getSession(false);
if(session != null)
{
final GenericPrincipal impersonatedPrincipal =
(GenericPrincipal) session.getAttribute("impersonatedPrincipal");
if (impersonatedPrincipal != null)
{
System.out.println( "Impersonating");
request = new
HttpServletRequestWrapper((HttpServletRequest)request)
{
public Principal getUserPrincipal()
{
return impersonatedPrincipal;
}
};
}
}
chain.doFilter(request, response);
I feel like I'm right on top of the solution. But I just can't seem to
get over the finish line. Thanks for you help.
Filter looks good. The other code looks sus.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
