RE: Weird CSRF prevention behavior
Chris CS> HTTP POST should not be prohibited unless I'm reading CS> both the code and the CSRF specs incorrectly. cjb> Pretend that it does. How would you solve that? CS> You have to manually add the CSRF token in each CS> in a hidden FORM parameter. It's doable, but it sucks to CS> have to do that across your whole application. Yeah, that would be tedious. In my old JSP days we had a function "htmFormBegin" that we called to auto-populate all the needed hidden fields on every page for every form. (It could have been a tag.) The discipline of using that function instead of hard coding all the forms made changes like that trivial. Ah well. CS> Application B has a feature where we present a web form to the user. CS> It's fairly simple (paraphrasing): CS> CS> cjb> What happens if you cheat? Can you use a redirect from cjb> B to A instead, or will that violate the filter rules? CS> That would be even more complicated. I'm looking for "simple" :) It's too bad the CSRF handling can't be offloaded to the load balancer instead. Or perhaps an exception list could be added to the TC filter. It sounds like, in your case, CSRF *should* be allowed as an exception between your 2 apps, if I understand it correctly. FWIW, even if my suggestions suck, I hope maybe that can provoke to "think outside the box" instead. -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
[ANN] Apache Tomcat 8.5.97 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.5.97. Apache Tomcat 8 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and JASPIC technologies. Apache Tomcat 8.5.97 is a bugfix and feature release. The notable changes compared to 8.5.96 include: - Background processes for a Container no longer execute while lifecycle operations are in progress for that Container. - Correct unintended escaping of XML in some WebDAV responses. - Use a 408 status code if a read timeout occurs during HTTP HTTP request processing instead of an HTTP 400 status. Please refer to the change log for the complete list of changes: https://tomcat.apache.org/tomcat-8.5-doc/changelog.html Downloads: https://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 7.x and 8.0: https://tomcat.apache.org/migration.html Please note that Tomcat 8.5.x will reach End-of-life (EOL) on 31 March 2024. For more information please visit https://tomcat.apache.org/tomcat-85-eol.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Apache Tomcat 10.1.17 Available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 10.1.17. Apache Tomcat 10 is an open source software implementation of the Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations specifications. Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without changes. Java EE applications designed for Tomcat 9 and earlier may be placed in the /webapps-javaee directory and Tomcat will automatically convert them to Jakarta EE and copy them to the webapps directory. This conversion is performed using the Apache Tomcat migration tool for Jakarta EE tool which is also available as a separate download for off-line use. Apache Tomcat 10.1.17 is a bugfix and feature release. The notable changes compared to 10.1.16 include: - Background processes for a Container no longer execute while lifecycle operations are in progress for that Container. - Correct unintended escaping of XML in some WebDAV responses. - Use a 408 status code if a read timeout occurs during HTTP HTTP request processing instead of an HTTP 400 status. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-10.1-doc/changelog.html Downloads: http://tomcat.apache.org/download-10.cgi Migration guides from Apache Tomcat 8.5.x and 9.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
channelStartOptions for cluster with static membership
To use *DeltaManager* with unicast (static membership), the Tomcat 8.5 documentation (https://tomcat.apache.org/tomcat-8.5-doc/config/cluster.html) states that the channelStartOptions should be equal to *3*. However, the value should be left as the default when using the *StaticMembershipService* according to the Tomcat 9.0 documentation ( https://tomcat.apache.org/tomcat-9.0-doc/config/cluster.html). Why does this distinction exist? Sincerely Manak Bisht
Use JAVA/CATALINA_OPTS arguments in server.xml
Hi, is it possible to use values passed as arguments through *JAVA_OPTS *or *CATALINA_OPTS *in the *server.xml*? Sincerely Manak Bisht
Re: Use JAVA/CATALINA_OPTS arguments in server.xml
> On Dec 12, 2023, at 09:11, Manak Bisht wrote: > > Hi, is it possible to use values passed as arguments through > *JAVA_OPTS *or *CATALINA_OPTS > *in the *server.xml*? Yes. For example, setting the port number in server.xml for the default connector: And using the following in setenv.sh: CATALINA_OPTS="-Dtest_port=9090” results in Tomcat listening on port 9090 rather than 8080. Removing the CATALINA_OPTS setting restores the port to its default. This is described somewhat tersely here: https://tomcat.apache.org/tomcat-10.1-doc/config/systemprops.html - Chuck
[ANN] Apache Tomcat 9.0.84 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 9.0.84. Apache Tomcat 9 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and JASPIC technologies. Apache Tomcat 9.0.84 is a bugfix and feature release. The notable changes compared to 9.0.83 include: - Background processes for a Container no longer execute while lifecycle operations are in progress for that Container. - Correct unintended escaping of XML in some WebDAV responses. - Use a 408 status code if a read timeout occurs during HTTP HTTP request processing instead of an HTTP 400 status. Along with lots of other bug fixes and improvements. Please refer to the change log for the complete list of changes: https://tomcat.apache.org/tomcat-9.0-doc/changelog.html Downloads: https://tomcat.apache.org/download-90.cgi Migration guides from Apache Tomcat 7.x and 8.x: https://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Typo in the release announcement
Hi all, In https://tomcat.apache.org/, there are three places of >occurs during HTTP HTTP request processing with an extra `HTTP`. Thanks,Ahmed
Re: channelStartOptions for cluster with static membership
Manak, On 12/12/23 10:05, Manak Bisht wrote: To use *DeltaManager* with unicast (static membership), the Tomcat 8.5 documentation (https://tomcat.apache.org/tomcat-8.5-doc/config/cluster.html) states that the channelStartOptions should be equal to *3*. However, the value should be left as the default when using the *StaticMembershipService* according to the Tomcat 9.0 documentation ( https://tomcat.apache.org/tomcat-9.0-doc/config/cluster.html). Why does this distinction exist? Historical happenstance? The default is SND_RX_SEQ (1) | SEND_TX_SEQ (2) | MBR_RX_SEQ (4) | MBR_TX_SEQ (8) = 15. It occurs to be that with static membership, the values of MBR_* don't matter since there is no in-cluster chatter about membership: it's static(!). So using the default 15 instead of 3 for a static cluster shouldn't make any difference. So perhaps the documentation for charnnelStartOptions should say: " To start a channel without multicasting, you would want to ensure your channelStartOptions include Channel.SND_RX_SEQ | Channel.SND_TX_SEQ (i.e. 3). " * Full disclosure, I've never set up a Tomcat cluster and might have no idea what I'm talking about. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Typo in the release announcement
Anmed, On 12/12/23 12:51, Ahmed Ashour wrote: Hi all, In https://tomcat.apache.org/, there are three places of occurs during HTTP HTTP request processing with an extra `HTTP`. Thanks,Ahmed Thanks for the report. I've fixed the web site, but we won't bother to re-send the release announcement emails, since it's an obvious mistake and can't be misinterpreted in some bad way. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JAVA -tomcat- Request header is too large
Thank you, Chris. Right now, we're on 9.x line. But this is a very important and useful field for debugging which we should be aware of. Thanks, Amit -Original Message- From: Christopher Schultz Sent: Monday, December 11, 2023 2:02 PM To: users@tomcat.apache.org Subject: Re: JAVA -tomcat- Request header is too large CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. Amit, On 12/11/23 11:32, Amit Pande wrote: > Mark, Chris, > > What request ID we're referring to here? Perhaps, I missed some documentation? > > How do we enable it? Request-id is available in Tomcat 11.0 and 10.1 at the moment. Are you using either of those? I'm not seeing any documentation in the AccessLogValve for reporting that value anywhere... -chris > -Original Message- > From: Mark Thomas > Sent: Monday, December 11, 2023 3:06 AM > To: users@tomcat.apache.org > Subject: Re: JAVA -tomcat- Request header is too large > > > CAUTION: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. If you believe this is a phishing email, use the Report to > Cybersecurity icon in Outlook. > > > > On 08/12/2023 22:01, Christopher Schultz wrote: > > > >> Are request-ids always allocated, or only if they are "enabled"? > > Always allocated. > >> I think adding the request-id to this exception detail message might >> be helpful, even if the request-id hasn't been enabled in the access-log. >> >> WDYT? > > Good point. More widely, we should probably be adding the request ID to every > request related error message. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 9.0.83 addSslHostConfig JMX Operation Regression (Sample Code Attached)
I apologize for it being a bit rough - it's what I was using to
troubleshoot locally.
import static java.util.Objects.nonNull;
import java.lang.management.ManagementFactory;
import java.util.Arrays;
import java.util.HashMap;
import java.util.Map;
import java.util.Optional;
import java.util.function.Predicate;
import javax.management.MBeanInfo;
import javax.management.MBeanOperationInfo;
import javax.management.MBeanServer;
import javax.management.ObjectName;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.tomcat.util.net.SSLHostConfig;
import org.apache.tomcat.util.net.SSLHostConfigCertificate;
import org.apache.tomcat.util.net.SSLHostConfigCertificate.Type;
@javax.annotation.ManagedBean
public class MbeanFailure {
private static final Logger LOGGER = LogManager.getLogger();
private static final String LOCALHOST = "127.0.0.1";
private static final String SUBTYPE = "subType";
private static final String ADD_SSL_HOST_CONFIG_OP = "addSslHostConfig";
private static final Predicate NOT_LOCALHOST = Predicate.not(on
->
Optional.ofNullable(on).map(ObjectName::getCanonicalName).orElse("").contains(LOCALHOST));
private static final Predicate NOT_SUBTYPE = Predicate.not(on
->
Optional.ofNullable(on).map(ObjectName::getCanonicalName).orElse("").contains(SUBTYPE));
@javax.annotation.PostConstruct
public void run() throws Exception {
final MBeanServer server = ManagementFactory.getPlatformMBeanServer();
final SSLHostConfig config = new SSLHostConfig();
config.setProtocols("TLSv1.2");
config.setHostName("test.test.com");
config.setCiphers("TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256");
final SSLHostConfigCertificate cert = new SSLHostConfigCertificate(config,
Type.UNDEFINED);
config.addCertificate(cert);
final Map references = getObjectReferences(server,
"ProtocolHandler");
references.forEach((s, op) -> invoke(s, op, ADD_SSL_HOST_CONFIG_OP, new
Object[] {config}, new String[] {SSLHostConfig.class.getCanonicalName()}));
}
public Map getObjectReferences(final MBeanServer
server, final String discriminator) {
final Map results = new HashMap<>();
final Predicate extendedFilters =
NOT_LOCALHOST.and(NOT_SUBTYPE);
final Optional candidate = server.queryNames(null,
null).stream()
.filter(on -> nonNull(on.getCanonicalName()))
.filter(on -> on.getCanonicalName().contains(discriminator))
.filter(extendedFilters)
.findAny();
candidate.ifPresent(on -> results.put(server, on));
return Map.copyOf(results);
}
public Object invoke(final MBeanServer server, final ObjectName objectName,
final String method, final Object[] params, final String[] signature) {
try {
//This should return addSslHostConfig(SSLHostConfig, boolean)
final MBeanInfo info = server.getMBeanInfo(objectName);
final MBeanOperationInfo methodInfo = Arrays.stream(info.getOperations())
.filter(i -> i.getName().equals(method))
.findAny()
.orElseThrow(() -> new RuntimeException("Could not find method named" +
method));
LOGGER.error("Found available operation {}", methodInfo);
final Object result = server.invoke(objectName, method, params, signature);
return result;
} catch (final Exception e) {
throw new RuntimeException("Error invoking " + method + " with params " +
Arrays.toString(params) + " and signature " + Arrays.toString(signature),
e);
}
}
}
On Fri, Dec 8, 2023 at 4:55 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Daniel,
>
> On 12/7/23 13:25, Daniel Skiles wrote:
> > All,
> > I've been doing some testing, and I'm pretty sure the addSslHostConfig
> > operation on ProtocolHandler is busted in 9.0.83.
> >
> > In versions prior to 9.0.82, you can call the operation with a single
> > argument of type SSLHostConfig.
> >
> > In 9.0.82, that contract seems to have been broken, and you had to call
> > it with two arguments: an SSLHostConfig and a boolean.
> >
> > In 9.0.83, it seems as though both operations are present, but which one
> > is actually accessible at runtime is non-deterministic.
> >
> > This behavior presents through a direct invoke(...) call and via a JMX
> > Proxy object instantiated through JMX.newMBeanProxy.
> >
> > I have attached a sample file that reproduces the behavior (sometimes,
> > as it is nondeterministic).
> >
> > Is this a bug, or am I simply using the available feature incorrectly?
> >
> > If it is the former, how do I formally report this? If it is the
> > latter, what is the "correct" way to call this operation from JMX?
>
> I think your attachment was stripped. Can it be posted in-line?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
