I have a Spring-based RESTful API which is deployed to a Tomcat server. When I call this API like below (value of "para" has been URL-encoded) and debug it, value of "para" in controller method is "aaa bbb" which has already been URL-decoded.
GET http://MY-TOMCAT-SERVER/SOME-PATH?para=aaa%20bbb
However, when I run a SpringBoot-based local Test Automation case (not deployed anywhere) to test the same API, the value of "para" in controller method hasn't been URL-decoded.
Question is, what is the difference between the two scenarios and where is "para" URL-decoded in the first scenario?
Hopefully I can give you a hint for the first part of your question:
The Apache Tomcat server.xml contains an tag Connector, this tag can have an optional attribute URIEncoding. Example:
<Connector connectionTimeout="20000"
port="8080"
protocol="HTTP/1.1"
redirectPort="8443"
URIEncoding="UTF-8" />
So I think that Tomcat is responsible for the URI encoding. But I do not know how this is activated in an Embedded-Spring-Boot-Tomcat.
#See: How does URIEncoding = 'UTF-8' work?
#See: Apache Tomcat 8 Configuration Reference / The HTTP Connector
Related
To start with, we have two java applications.
One is traditional web app, generates war file which gets deployed in tomcat.
Another is spring boot application which generates jar file.
For SSL we have been provided with certificate file (.crt) and private key file (.key) files.
SSL has already been implemented for traditional application. It has been done by updating the server.xml file by adding below section and has been working successfully.
server.xml
<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol"
maxThreads="150" SSLEnabled="true" >
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
<SSLHostConfig>
<Certificate certificateKeyFile="/usr/local/tomcat/xyz-domain.key"
certificateFile="/usr/local/tomcat/xyz-domain.crt"
type="RSA" />
</SSLHostConfig>
</Connector>
I want to implement the similar thing for Spring boot application for embedded tomcat.
I have gone through many tutorials. All say things about .p12 format or .jks and to create some keystore from these files etc. I am bit confused now.
Can we follow the above xml section and configure embedded tomcat to behave same as traditional tomcat?
Or are there any limitations for embedded tomcat?
I followed below tutorial without success.
https://github.com/craig-rueda/tomcat-native-spring-boot-sample/blob/master/src/main/java/com/example/tcnativeapp/TcnativeappApplication.java
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!
In the Spring definition of a remote resource that is protected via OAuth2 to which the client application wants access, I set use-current-uri to true, in other words, the current URI should be used as a redirect (if available). It looks like:
<oauth:resource id="myResourceId" type="authorization_code"
client-id="${clientId}" client-secret="${clientSecret}"
access-token-uri="${accessTokenUri}"
user-authorization-uri="${userAuthorizationUri}"
use-current-uri="true"
scope="myScope"
pre-established-redirect-uri="${preEstablishedRedirectUri}"/>
Now the problem is, the Spring Security OAuth2 client will pick up the current internal Tomcat URL instead of the public web application's URL. The scenario is Tomcat server sitting behind Apache server, which results in two sets of URLs:
The public web application's URL is http://example.com/users/login
The internal Tomcat URL is http://localhost:8080/myapplication/users/login
Because the redirection URL is for the authorization server (e.g., Twitter, ORCID) to use to send back the authorization code, the public web application's URL should be used, not the internal one.
By the way, I'm using the following version of spring-security-oauth2:
spring-security-oauth2-1.0.5.RELEASE
spring-core-3.1.2.RELEASE
spring-security-core-3.1.3.RELEASE
Wonder if there is a way to tell Spring to use the public URL. Thanks.
Inside your tomcat conf/server.xml's connector element , try setting your public URLs that front tomcat like this:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
proxyName="example.com"
proxyPort="443" (or whatever port you are using, same goes for scheme )
scheme="https" />
This way tomcat's internal getServerName and getServerPort methods will start giving the correct values which hopefully should create the correct URL.
You might also want to configure your webserver to route requests falling at
http://example.com/users/login to http://localhost:8080/myapplication/users/login if not already done.
I am developing a webapp with an embedded webservice with Axis2 using Maven.
The service implementation is a POJO with RPC-style interaction, the target appserver is Tomcat running the Axis2 servlet.
The "Hello world" works but now I need to configure some global axis2 settings in the axis2.xml file (placed under WEB-INF/conf).
Please provide or point to a simple configuration for axis2.xml for this common environment.
The default taken from the binary distribution has too many features activated (hotdeploy?) and also causes this problem:
<soapenv:Reason>
<soapenv:Text xml:lang="en-US">
The ServiceClass object does not implement the required method
in the following form: OMElement ping(OMElement e)
</soapenv:Text>
</soapenv:Reason>
As a reference: http://axis.apache.org/axis2/java/core/docs/servlet-transport.html says to configure the servlet transport in this way, but it does not solve the issue.
<transportReceiver name="http" class="org.apache.axis2.transport.http.AxisServletListener"/>
Apparently the problem is that the default axis2.xml sets raw xml messageReceivers, instead of the RPC ones.
Try to add this to the services.xml for the developed service, should fix the problem.
<messageReceivers>
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-only"
class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver" />
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out"
class="org.apache.axis2.rpc.receivers.RPCMessageReceiver" />
</messageReceivers>
"Solution that worked for me was adding the operation tag in the service.xml against the Java Service method name:
<operation name="sayHello" >
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out" class="org.apache.axis2.rpc.receivers.RPCMessageReceiver" />
</operation>
<parameter name="ServiceClass" locked="false">com.learning.webservices.pojo.HelloService</parameter>
The thing is that Apache CXF takes the location attribute from WSDL file and replaces it with the server's URL, including the port. Is there any way to set the port manually to a specific value? If it was possible, I would like to do this from Spring...
The relevant part from WSDL:
...
<port binding="ns:binding" name="someUrl">
<soap:address location="http://localhost/url"/>
</port>
...
I took the basic endpoint configuration from Apache CXF website and added the publishedEndpointUrl="http://newurl:port/..." attribute to jaxws:endpoint element.