My code is working on tomcat 8 version 8.0.33 but on 8.5.4 i get :
An invalid domain [.mydomain] was specified for this cookie.
I have found that Rfc6265CookieProcessor is introduced in tomcat 8 latest versions.
It says on official doc that this can be reverted to LegacyCookieProcessor in context.xml but i don't know how.
Please let me know how to do this.
Thanks
You can try in context.xml
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
reference:
https://tomcat.apache.org/tomcat-8.0-doc/config/cookie-processor.html
Case 1: You are using Standalone Tomcat & have access to change files in tomcat server
Please follow answer by #linzkl
Case 2: You are using Standalone Tomcat but you don't have access to change files in tomcat server
Create a new file called context.xml under src/main/webapp/META-INF folder in your application & paste the content given below
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>WEB-INF/tomcat-web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
</Context>
When you deploy your application in Standalone Tomcat, the context.xml file you placed under META-INF folder will override the context.xml file given in tomcat/conf/context.xml
Note: If you are following this solution, you have to do it for every single application because META-INF/context.xml is application specific
Case 3: You are using Embedded Tomcat
Create a new bean for WebServerFactoryCustomizer
#Bean
WebServerFactoryCustomizer<TomcatServletWebServerFactory> cookieProcessorCustomizer() {
return new WebServerFactoryCustomizer<TomcatServletWebServerFactory>() {
#Override
void customize(TomcatServletWebServerFactory tomcatServletWebServerFactory) {
tomcatServletWebServerFactory.addContextCustomizers(new TomcatContextCustomizer() {
#Override
public void customize(Context context) {
context.setCookieProcessor(new LegacyCookieProcessor());
}
});
}
};
}
Enabling the LegacyCookieProcessor which is used in previous versions of Tomcat has solved the problem in my application. As linzkl mentioned this is explained in Apache's website https://tomcat.apache.org/tomcat-8.0-doc/config/cookie-processor.html.
The reason is that the new version of Tomcat does not understand the . (dot) in front of the domain name of the Cookie being used.
Also, make sure to check this post when you are using Internet Explorer. Apparently, it's very likely to break.
You can find context.xml in the following path.
tomcat8/conf/context.xml
<?xml version="1.0" encoding="UTF-8”?>
<!-- The contents of this file will be loaded for each web application —>
<Context>
<!-- Default set of monitored resources. If one of these changes, the -->
<!-- web application will be reloaded. -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
<!-- Uncomment this to disable session persistence across Tomcat restarts -->
<!-- <Manager pathname="" /> -->
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor"/>
</Context>
The problem is still with Tomcat9. Same process need to follow for Tomcat 9 to set the class.
Add the class in context.xml file.
If you are using eclipse to run the application, need to set in the context.xml file in the server folder. Refer the below screenshot for more reference.
Hope this helps someone.
SameSite issue in tomcat version < 8.5.47 has resolved
In Tomcat 8.5.47 and bellow (Tomcat 8 versions), setting CookieProcessor tag to enable same site (as given bellow) in context.xml does not work due to a bug in Tomcat.
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" sameSiteCookies="none" />
If you find in this situation where it is not a easy thing to upgrade tomcat immediately (which I faced recently), or if you find any other case where you just need custom processing in cookies; You can write your own CookieProcessor class to get around.
Please find a custom CookieProcessor implementation and details of it's deployment steps here.
In my case I wrote a custom CookieProcessor based on LegacyCookieProcessor source code that allows tomcat 8.5.47 to enable SameSite attribute in cookies.
As mentioned by #atul, this issue persists in Tomcat 9. It will most likely persist moving forward with all future versions of Tomcat, since this is the new standard.
Using the legacy cookie processor (by adding the line above to the context.xml file) is working well for us. However, the true 'fix' is to adjust how your cookie is formed in the first place. This will need to be done in your application, not in Tomcat.
The new cookie processor does not allow the domain to start with a . (dot). Adjusting your cookie (if possible) to start with a value other than that will fix this problem without reverting to the old, legacy cookie processor.
Also, it should be obvious, but I didn't see it mentioned above: after updating the context.xml file, you need to restart the Tomcat service for the change to take effect.
Cheers!
Related
Is there anyone can tell me how to add SameSite:Strict to all cookies created in spring 5.1? I know in spring 4, this attribute was not supported. But since Spring 5.1, It can be as declare at here!
But I don't know how to apply this to my project? Where should I put it? Please help me! Thanks!
I cannot add SameSite attribute to my project using Spring because Object javax.servlet.http.Cookie hasn't supported this attribute. But I could custom cookie header in Apache tomcat (version 9.0.11) by add the following line to conf/context.xml:
<Context allowCasualMultipartParsing="true">
...
<CookieProcessor className="org.apache.tomcat.custom.coyote.TomcatCoyoteCustomer"/>
</Context>
And then create a project "CustomCookieProcessor" with TomcatCoyoteCustomer class that extends Rfc6265CookieProcessor class, override method generateHeader and append "SameSite:Strict" to cookie header. Finally, I copy jar file of "CustomCookieProcessor" project to folder lib of Tomcat. You can read more detail about CookieProcessor of Apache Tomcat at here!
In WAS Full Profile you can change the values for env-entries defined in an application's web.xml file while and after deployment. Is there any such feature in WebSphere Liberty profile?
Sample env-entry:
<env-entry>
<description>Some Config String</description>
<env-entry-name>MyConfigString</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>Dev-Value to be replaced in Production during deployment</env-entry-value>
</env-entry>
This env-entry is injected with an #Resource(name = "MyConfigString") annotation.
The infocenter for IBM Worklight (which runs on Liberty) describes a way using jndiEntry elements in server.xml . I tried this on Liberty 8.5.5.3 but it does not work and still injects the default value from web.xml.
Has anybody found a working way to configure env-entry values in Liberty?
The Liberty profile doesn't currently support configuring bindings without modifying the ibm-*-bnd.xml files in the application. As a workaround, you can use:
#Resource(lookup="MyConfigString")
...in the application and:
<jndiEntry jndiName="MyConfigString" value='"xyz"'/>
...in server.xml as described in the knowledge center.
Setup:
Tomcat 6.0.16
Struts 2.1.6
Apache Commons Logging 1.0.4
Log4J 1.2.17
What I did:
Change in server.xml:
<Context path="/" .../></Context>
to
<Context path="/shop" .../></Context>
The issues:
Everything in the application is working fine (on the first glance). All links are correct and working etc.
Now I discovered that the Loggers using Commons Logging (with Log4J) (usually the Loggers in Spring, Struts and OGNL) are using a different logger configuration than the default used before. Loggers using Log4J directly in the application are working fine with this configuration.
For debugging purpose I have a JSP listing all the loggers with:
Logger.getRootLogger().getLoggerRepository( ).getCurrentLoggers()
But the "commons logging logger" are not listed anymore, although I could verify that they exist if I debug the code.
The question:
How do I find the other configuration/root logger?
Do I have to change anything in the struts configuration (or somewhere else) in relation to the context path change?
Any ideas what the issue might be here?
Edit: I'm getting closer:
The platform I am using is loading a minimal logging at start up. Before changing the context the advanced logging was loaded right afterwards and everything was fine. For some reason the listener of the web.xml (Spring initialization, etc.) is now running before the advanced logging is loaded. These classes are using the apache commons logging api and get loggers assigned basing on the simple root logger. Right afterwards the root logger is replace by the platform but the commons loggers are not updated with the new configuration.
New question:
As I stated below, changing anything in the platform is no option. So why did the listener run earlier when I change the context and how can I prevent this.
For the sake of the moment Apache Tomcat uses JDK logging. If you didn't place commons-logging.properties file to your source dir the default logger using commons logging will be log4j. Anyway the Tomcat will not use that logging because it needs a special configuration to tell it to use log4j.
The root logger is what you use in the log4j configuration. For example
log4j.rootLogger=ERROR,Console
Changing context path is nothing related to the logging used by application.
I didn't see any issue with logging rather that in recent releases regarding implementation priority.
The logging creates a dependency between multiple tomcat web application and due this fact requires a specific order of loading this modules. Renaming the context to "/shop" leads to an other order as StandardContext.filterDefs is a simple HashMap and does not preserve the order of the server.xml.
I could fix my issues in running the required steps in a listener.
web.xml
<listener>
<listener-class>com.[...].InitListener</listener-class>
</listener>
InitListener.java
package com.[...];
public class InitListener
{
static
{
// init Log4J, etc.
}
}
{code}
(Btw. Listener order should be identical to the web.xml)
I am trying to get Spring working with tomcat JNDI resource to access my database. My project works if a META-INF/context.xml in my project with the resource information but once I remove it it stops.. why.
If you deploy a Web application in Tomcat, in the deployment process, Tomcat will copy the META-INF/context.xml file in $CATALINA_HOME/conf/ so the context will be available for your application. Take in mind, that if you remove context.xml from you application because you dont want it, you also have to delete it manually from $CATALINA_HOME/conf/
If you have edited the server.xml for including your dababase resource and is not working when you remove context.xml it could be because you made some mistake defining your resourde in server.xml
UPDATED:
When resource is in server.xml, in context you should make a reference to global resource in server.xml. For example:
<Context crossContext="true" reloadable="true" >
<ResourceLink name="jdbc/myApp" type="javax.sql.DataSource" global="jdbc/myApp" />
</Context>
This is unrelated to Spring.
To use JNDI you are expected to define the various resources either as global configuration or as application specifici configuration. For example JNDI DataSource Configuration
Why do you expect it to work in any other case? How would Tomcat know which resources to provide if you don't define them?
UPDATE:
You define a resouce in your server.xml but you have to associate the resource with your web application. That is why you also need to modify context.xml
been struggling to find a way to configure Tomcat 7.0.11 so that my web application would use project stage setting from Tomcat's config. So far - no luck. The idea is to set this property in Tomcat server/host/application wide but not to set it in web.xml. Any ideas? I am using MyFaces JSF 2 implementation 2.0.5.
The specification says that the JSF implementation looks up the Project Stage using JNDI under java:comp/env/jsf/ProjectStage. If not found it uses the context parameter javax.faces.PROJECT_STAGE from your web.xml. This means that if defined/found on your Tomcat using JNDI, the value of preferred over the web.xml setting.
There are two things you can do:
Option 1: Overwrite the context parameter: This means that context parameter is set/overwritten using the Tomcat server.xml or context.xml. You need to put this in your <Context>-tag:
<Parameter name="javax.faces.PROJECT_STAGE" value="Production" override="false" />
Careful: override="false" here means that this parameter can NOT be overriden by the web.xml (not the other way around)!
Option 2: Configure a resource that can be found using JNDI: By using this that JSF implementation can resolve the project stage using the JNDI lookup.
<Environment name="jsf/ProjectStage" value="Production" type="java.lang.String" override="false"/>
You can also move this to the <GlobalResources>-tag in your server.xml. In this case you would need to reference this in your <Context>-tag by using <ResourceLink>-tag.