Re: How does the user principal get set on the servlet container session?
What should happen if
session.getAttribute("javax.security.auth.subject") returns a non-null
value?
-Terence Bandoian
On 1/30/2024 5:15 PM, Ryan Esch wrote:
>From what I understand, the container knows if a user is authenticated by
using the session id passed to it and then looking up the user principal. If this
is non-null, the user is authenticated. I am using web.xml with security
constraints and UsersRoleLoginModule defined in jaas.conf which is working fine. I
want to add an additional method of login.
How do I set the principal on the session in my custom login module? I have
tried a number of things, including:
HttpSession session = request.getSession();
// Retrieve or create the Subject
Subject subject = (Subject) session.getAttribute("javax.security.auth.subject");
if (subject == null) {
subject = new Subject();
session.setAttribute("javax.security.auth.subject", subject);
}
subject.getPrincipals().size());
Principal customPrincipal = new CustomPrincipal("Random Username");
subject.getPrincipals().add(customPrincipal);All my calls to
request.getUserPrincipal() are null so of course my custom login
fails.Alternatively/additionally, can I configure the container to also check
for an access token for authentication?
Thank you for any input or advice. I'd be happy to share additional details.Ryan
How does the user principal get set on the servlet container session?
>From what I understand, the container knows if a user is authenticated by
>using the session id passed to it and then looking up the user principal. If
>this is non-null, the user is authenticated. I am using web.xml with security
>constraints and UsersRoleLoginModule defined in jaas.conf which is working
>fine. I want to add an additional method of login.
How do I set the principal on the session in my custom login module? I have
tried a number of things, including:
HttpSession session = request.getSession();
// Retrieve or create the Subject
Subject subject = (Subject) session.getAttribute("javax.security.auth.subject");
if (subject == null) {
subject = new Subject();
session.setAttribute("javax.security.auth.subject", subject);
}
subject.getPrincipals().size());
Principal customPrincipal = new CustomPrincipal("Random Username");
subject.getPrincipals().add(customPrincipal);All my calls to
request.getUserPrincipal() are null so of course my custom login
fails.Alternatively/additionally, can I configure the container to also check
for an access token for authentication?
Thank you for any input or advice. I'd be happy to share additional details.Ryan
Re: Rotating/archiving catalina.out
One option (hacky workaround) is to try using "swallowOutput" which may mitigate the worst of your issue. (Beyond a rewrite with a logging framework) https://tomcat.apache.org/tomcat-9.0-doc/config/context.html -Tim On Mon, Jan 29, 2024 at 3:28 PM Aryeh Friedman wrote: > We need to shrink the size of catalina.out but looking at the logging > documentation I do not see any way to do this with the standard > logging.properties (or else where). Due to the nature of the > production site we never bring it completely down unless we must (life > critical 24/7/365) > > Specifically we have a fair number of System.out.println's with > debugging information to it and we dumb stack traces into it also. > And without stopping and restarting tomcat we want to make it so there > is periodic rotation of catalina.out to some other file? (note stack > traces do go to the dated one but not the System.out.println's) > >
Re: Rotating/archiving catalina.out
On 2024/01/29 20:28:05 Aryeh Friedman wrote: > We need to shrink the size of catalina.out but looking at the logging > documentation I do not see any way to do this with the standard > logging.properties (or else where). Due to the nature of the > production site we never bring it completely down unless we must (life > critical 24/7/365) > > Specifically we have a fair number of System.out.println's with > debugging information to it and we dumb stack traces into it also. > And without stopping and restarting tomcat we want to make it so there > is periodic rotation of catalina.out to some other file? (note stack > traces do go to the dated one but not the System.out.println's) If you use the FreeBSD port, it will automatically use commons-daemon. JSVC does support SIGUSR1 with reopening logs: https://github.com/apache/commons-daemon/blob/6a95175ba875977a59fa4be2e99d80d2fa8d053a/src/native/unix/native/jsvc-unix.c#L124-L127 Then, you can use newsyslogd to rotate with SIGUSR1. This works for me for ages now: /usr/local/ldadocgen/prod/tomcat-1/logs/catalina.outldadocgen:ldadocgen 064030*@T00GBXP/var/run/tomcat_ldadocgen_prod_1.pid SIGUSR1 Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 release plan
On 30.01.24 12:10, Kambhapati, Sindhuri wrote: Hi, Can you give me link for the tomcat forum please. https://tomcat.apache.org/lists.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 release plan
Hi, Can you give me link for the tomcat forum please. On Tue, Jan 30, 2024 at 4:34 PM Torsten Krah wrote: > Am Dienstag, dem 30.01.2024 um 16:29 +0530 schrieb Kambhapati, > Sindhuri: > > Can we get a confirmation as to how long tomcat 9 releases would be > > happening or there would be support for the existing one's. > > Please look / search in the archives, this was already discussed a few > days ago, topic was: > > EOL - Tomcat versions > > No need to do another thread with the same topic. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- The information contained in this email message and its attachments is intended only for the private and confidential use of the recipient(s) named above, unless the sender expressly agrees otherwise. Transmission of email over the Internet is not a secure communications medium. If you are requesting or have requested the transmittal of personal data, as defined in applicable privacy laws by means of email or in an attachment to email, you must select a more secure alternate means of transmittal that supports your obligations to protect such personal data. If the reader of this message is not the intended recipient and/or you have received this email in error, you must take no action based on the information in this email and you are hereby notified that any dissemination, misuse or copying or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the original message.
Re: Tomcat 9 release plan
Am Dienstag, dem 30.01.2024 um 16:29 +0530 schrieb Kambhapati, Sindhuri: > Can we get a confirmation as to how long tomcat 9 releases would be > happening or there would be support for the existing one's. Please look / search in the archives, this was already discussed a few days ago, topic was: EOL - Tomcat versions No need to do another thread with the same topic. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 9 release plan
Hi, I wanted to know till how long will tomcat 9 releases be supported. We need to plan our project based on this. As, we are on vaadin and it has dependency on tomcat 9's javax package which got changed to jakarta in tomcat 10. I read somewhere that tomcat 9 is being parallelly developed along with 10 to take care of this problem. Can we get a confirmation as to how long tomcat 9 releases would be happening or there would be support for the existing one's. -- Thanks, Sindhuri -- The information contained in this email message and its attachments is intended only for the private and confidential use of the recipient(s) named above, unless the sender expressly agrees otherwise. Transmission of email over the Internet is not a secure communications medium. If you are requesting or have requested the transmittal of personal data, as defined in applicable privacy laws by means of email or in an attachment to email, you must select a more secure alternate means of transmittal that supports your obligations to protect such personal data. If the reader of this message is not the intended recipient and/or you have received this email in error, you must take no action based on the information in this email and you are hereby notified that any dissemination, misuse or copying or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the original message.
