Re: Admin password for Tomcat
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. 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. 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. 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. How do I go about removing the real principal? 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. 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 ); 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. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Admin password for Tomcat
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
Re: [EXT] Datadog _ JMX Integration facing connection issues.
Sai Vamsi, On 12/27/23 04:12, Bodavula, Sai Vamsi Mohan Krishna (TR Technology) wrote: Hello chris, thanks for adding a point and I may have missed your email. below is some of the points, which showed me how tomcat is being started in my application. * Line 19: INFO [main][2023-12-27 09:00:38,983] - org.springframework.boot.web.embedded.tomcat.TomcatWebServer.initialize(TomcatWebServer.java:108) - Tomcat initialized with port(s): 9109 (http) 10109 (http) Line 21: INFO [main][2023-12-27 09:00:39,008] - org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:173) - Starting service [Tomcat] Line 22: INFO [main][2023-12-27 09:00:39,009] - org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:173) - Starting Servlet engine: [Apache Tomcat/9.0.75] Line 134: INFO [lab1workflow4scalsvc2zus1][version:1.7.99-alpha.1130][traceId:][spanId:][parentSpanId:][spanExportable:][main][2023-12-27 09:01:01,057]- org.springframework.boot.web.embedded.tomcat.TomcatWebServer.start:Line 220 - Tomcat started on port(s): 9109 (http) 10109 (http) with context path '/lab1workflow4scalsvc2zus1 * to launch tomcat, we are not using any command here, I am trying to build my code to an image, making some helm chart out of it, using helm chart to install in my AKS containers. This may be the first time you mentioned Spring. I don't know if Spring uses any of those environment variables for anything at all. You may need to consult the Spring documentation to see how best to set all of those JVM parameters. -chris From: Christopher Schultz Sent: Thursday, December 14, 2023 20:33 To: users@tomcat.apache.org Subject: Re: [EXT] Datadog _ JMX Integration facing connection issues. Sai Vamsi, On 12/14/23 00:26, Bodavula, Sai Vamsi Mohan Krishna (TR Technology) wrote: Hai Chuck., Thanks for jumping in., thats what my concern is. as previously added by Chris, I have added my annotations in Catalina_opts ., Which is preferred by Java_Process for adding the annotations., But Here by using catalina_opts., they are not reflecting. where as adding them in java-tool-options., Makes a process with Tomcat and a process that listens on the mentioned port., but throws port is already binded., as its an environment variable, its already looking for a port, where as its already created., throws binding error. Yesterday ., I thought of adding both the formats, adding java_tool_opts and Catalina opts., inorder to utilize the previous thigns., as below - name: JAVA_TOOL_OPTIONS value: {{ .Values.deployment.javaVMMemoryArgument }} - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP - name: CATALINA_OPTS value: >- -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=49151 -Djava.rmi.server.hostname=$POD_IP -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.local.only=false -Xms2048M -Xmx10240M Java_tool_opts are as : -XX:+UseStringDeduplication -XX:+UseContainerSupport -Dcom.sun.management.jmxremote just added to initiate a JMX process., but nothing is working out., I would like to request you for further inputs How are you launching Tomcat itself? Are you using catalina.sh or something similar, or do you use some kind of embedded-launch? It sounds to me like using CATALINA_OPTS is causing Tomcat not to start at all. If you use JAVA_TOOL_OPTIONS (which Tomcat ignores), Tomcat will start but won't initialize JMX in the way you want it to. The solution is to look at the log files that are produced when Tomcat launches (or fails to launch). Are you able to observe those? It would be great to see the exact command Helm (or whatever) uses to attempt to launch Tomcat, and then the stdout/stderr of that attempt. The diagnostic messages shown when a JVM refuses to start are usually pretty good. Same thing with Tomcat, though Tomcat usually starts even if e.g. no connectors are successfully started because there is no actual requirement for Tomcat to listen to any ports. -chris From: Chuck Caldarale Sent: Thursday, December 14, 2023 00:28 To: Tomcat Users List Subject: Re: [EXT] Datadog _ JMX Integration facing connection issues. On Dec 13, 2023, at 10:36, Bodavula, Sai Vamsi Mohan Krishna (TR Technology) wrote: as you just asked ., I do have a process with Catalina. root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# netstat -tulpn Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp6 0 0 :::34753:::*LISTEN