My Spring Boot application running on IIS Server generating custom error page for remote request finding error code 401 at header. I want to disable it. There should be no custom error page in response data. Desired behavior is there as default in Apache server. Though IIS Server can be configured to prevent generating custom error page for remote request, I want it to be configured from my application (Web Configuration point may be). Is it possible in Spring?
In your web.xml add this:
<error-page>
<error-code>401</error-code>
<location>/errors/unauthorised</location>
</error-page>
Then add a controller like this:
#Controller
#RequestMapping("/errors")
public class ApplicationExceptionHandler {
#ResponseStatus(HttpStatus.UNAUTHORIZED)
#RequestMapping("unauthorised")
public ModelAndView unauthorizedError(){
return new ModelAndView("errors/error.jsp");
}
}
Add a web.config file to your app's webapp directory (app/src/main/webapp). web.config file should consist:
<configuration>
<system.webServer>
<httpErrors errorMode="Detailed" existingResponse="Auto" />
</system.webServer>
</configuration>
this will cause IIS web server to set error mode to 'Detailed' which will prevent generating custom error page.
Related
When using Tomcat included in Boot, if a 404 error occurs, it succeeded in moving to the Custom page. However, if an external Tomcat is used, if a 404 error occurs, it will go to Tomcat's 404 page.
In situations where I can't explain tomcat's settings(For example i can't do setting error page in web.xml
), Could this issue be solved in Spring Boot?
Springboot has inbuilt tomcat server which will be started.
In following example xyz.html will work as your web.xml
#Bean
public ErrorPageRegistrar errorPage() {
return registry -> registry.addErrorPages(new ErrorPage(HttpStatus.NOT_FOUND, "/xyz.html")); }
I'm setting up exception handling logic for a multipart project with common error page (that is hosted in other part of the project). When I tried to redirect to external URL on exception, tomcat 8.5.39 is showing default error instead. Funny thing is, this seems to work just fine in tomcat 8.5.38
I've tried many different exception handling techniques, but they all seem not to work for external redirects.
So currently, i have something like this in my web.xml file:
...
<error-page>
<error-code>404</error-code>
<location>/error/error404</location>
</error-page>
...
and for my Spring controller,
#Controller
#RequestMapping(value = "/error")
public class ErrorHandler{
...
#GetMapping(value = "error404")
public String error404(){
return "redirect:http://{myproject}/{404errorPage}";
}
...
}
I'm expecting this code to redirect the user to http://{myproject}/{404errorPage} when 404 error occurs, which works just fine in tomcat 8.5.38. But on 8.5.39, they seem to have changed error handling logic, and it will display default error page(browser default 404 page).
Any input or idea would be tremendously helpful.
This is a known regression in 8.5.39 which is fixed in the just released 8.5.40.
i have deployed my web application in WebSphere 7. this application is build using spring and jsp servlets. some times when it get deployed due to errors it shows the following attached image like errors.
i have handled my web application errors as follows, by redirecting the errors to spring controller.
<error-page>
<error-code>500</error-code>
<!--Internal server error -->
<location>/error.p?message=500</location>
</error-page>
<error-page>
<error-code>403</error-code>
<!--Forbidden -->
<location>/main.p</location>
</error-page>
but it only works when the web application is successfully deployed. when deployment error happens WebSphere shows full error message like above.
is there any way to hide this error page and add custom error page in websphere when such deployment errors happens?
If you have an Apache server (or other) in front of your WebSphere, you may use it to redirect error 500 on a custom static web page.
Since you're using Spring, if this error can occur often, you can try to use lazy bean initialization on the remoteOMSConnectorWS (See LazyInitTargetSource). This would delay bean instantiation until its first use, most likely after webapp complete startup. In this case, your error configuration from web.xml could be used.
But I want to use Spring security.
I think i have to use DispatcherServlet and its configuration in web.xml
I am developing an application that is nor jsp nor jsf project, i am going to make all connection based on javascript/ajax/jquery via server communication.
Thus i do not want to map my xhtml pages to a controller.
But i have a single controller with #RequestMapping(/auth/login) i only want it to run when i request /auth/login this is not the problem, it is working excellently.
But when i use
spring
org.springframework.web.servlet.DispatcherServlet
contextConfigLocation
classpath:META-INF/spring-servlet.xml
1
spring
/heythere/*
and call http://localhost:8080/app/myhtml.xhtml it tells me i have no mapping for this uri.
I do not want mapping, nor controller to run, only want to see the page.
But DispatcherServlet needs to map it, how can i tell DispatcherServlet not to map ordinary xhtml pages?
Option 1:
Inside your spring web mvc application context XML you should put something like:
<mvc:view-controller path="/myhtml.xhtml"/>
The downside is you'll have to do this per page.
Option 2:
Use a Resource Handler:
<!-- Handles HTTP GET requests for /resources/** by efficiently serving up static resources -->
<mvc:resources location="/, classpath:/META-INF/web-resources/" mapping="/static/**"/>
Your page would be visible like http://localhost:8080/app/static/myhtml.xhtml.
More info can be found in Spring's Doc.
I'd like to be able to do cross-context request forwarding in Tomcat with the Tuckey URLRewrite filter. For example, I'd like to be able to route an incoming request with an SEO-/user-friendly URL like http://example.com/group-elements/300245/some-descriptive-text, where "group-elements" isn't the name of a deployed application, to a URL mapped to a Java Spring controller method for application 'foo', like http://example.com/foo/app/group/300245/elements. I'm using Tomcat 7.0.27 and URLRewrite 3.2.0; I'm working with Java Spring 3.1 web applications.
The URLRewrite 3.20 documentation notes an optional 'context' attribute for the 'to' filter parameter element:
If your application server is configured to allow "cross context" communication then this attribute can be used to forward (and only forward, not redirect or other "to" types) requests to a named servlet context.
On Tomcat, for instance, the application contexts in the server configuration (server.xml or context.xml) need the option crossContext="true". For instance, the two applications mentioned before ("app" and "forum") have to be defined as:
<Context docBase="app" path="/app" reloadable="true" crossContext="true"/>
<Context docBase="forum" path="/forum" reloadable="true" crossContext="true"/>
Given that and the original discussion about the feature, the 'context' attribute seems to be what I'm looking for. However, I haven't been able to properly enable cross-context request forwarding.
Here's my 'Context' entry application 'foo' in conf/server.xml:
<Context docBase="foo" path="/foo" reloadable="true" crossContext="true"/>
I have my urlrewrite.xml file and web.xml file in webapps/ROOT/WEB-INF/. Here's what they look like:
urlrewrite.xml:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.2//EN"
"http://tuckey.org/res/dtds/urlrewrite3.2.dtd">
<urlrewrite>
<rule>
<from>baz</from>
<!-- Note: this 'to' element's value has an error. See the edit at bottom of this post for corrected version. -->
<to context="foo">/foo/app/group/300245/elements</to>
</rule>
</urlrewrite>
web.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd" version="2.5">
<filter>
<filter-name>UrlRewriteFilter</filter-name>
<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
<init-param>
<param-name>logLevel</param-name>
<param-value>WARN</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>UrlRewriteFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</web-app>
The rule defined above in urlrewrite.xml is intentionally basic and hard-coded. In this case I'm simply trying to get the cross-context aspect of the rule working before developing the regular expressions in 'to' and 'from'.
When I request http://example.com/baz with that rule in place, Tomcat returns a 404 error saying "The requested resource (/baz) is not available." I've tried a few variations in the 'to' filter parameter, but nothing has worked yet. And I haven't been able to find any examples of how 'context' should be used.
Any ideas on how I could get this kind of cross-context request filtering to work? Is it even possible? I imagine I might be able to achieve what I'm trying to do by renaming foo.war to ROOT.war or changing the root application as mentioned here, but I'd like to try doing this via URLRewrite unless doing so is infeasible or a bad idea on its face.
If showing more of my configuration would help, please let me know. Thanks in advance for any input.
Edit:
Thanks to Christopher Schultz for the helpful answer. In my case, the problem was caused by two things: 1) not having a context.xml file in webapps/ROOT/META-INF, and 2) having an error in the 'to' element in the URL rewrite rule in webapps/ROOT/WEB-INF/urlrewrite.xml.
The fix involved putting a proper context.xml file in webapps/ROOT/META-INF. For reference for anyone else that encounters this problem, that file ended up looking like this:
webapps/ROOT/META-INF/context.xml
<?xml version='1.0' encoding='utf-8'?>
<Context docBase="ROOT" path="/" reloadable="true" crossContext="true" />
As Schultz mentions, it's only necessary for a context with crossContext="true" to be defined for the context implied in the 'from' element in a given URL rewrite rule (here, that's ROOT). It is not necessary to explicitly define a context for the application in the 'to' URL rewrite rule. In other words, you shouldn't need to manually create a context.xml file for that application -- so continuing the example above, you would not need to manually define and put a context.xml file into webapps/foo/META-INF/.
Schultz's answer reflects the recommendations for defining a context in the official Tomcat documentation: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context.
The problem was also caused by the fact that the URL rewrite rule in my initial post had an error. The correct version should have been:
urlrewrite.xml:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.2//EN"
"http://tuckey.org/res/dtds/urlrewrite3.2.dtd">
<urlrewrite>
<rule>
<from>baz</from>
<!-- Note: the use of '/app' instead of '/foo/app/' below -->
<to context="foo">/app/group/300245/elements</to>
</rule>
</urlrewrite>
If your (real) webapp is deployed to /foo and you want to on-the-fly rewrite URLs like /group-elements/baz to forward (not redirect) to /foo/app/group/300245/elements, then you're going to have to deploy your rewrite filter to one of two places: /group-elements or /.
The above configuration appears to be deploying to ROOT (which is /) but then mapping the URL /baz to /foo/app/group/300245/elements. Instead, you probably want this:
<rule>
<from>/group-elements/baz</from>
<to context="foo">/foo/app/group/300245/elements</to>
</rule>
It looks like you were trying to hit http://example.com/baz which I would have expected to work. The last bit of magic is going to be making the ROOT context cross-context (note that your webapp does NOT need to be cross-context: only the urlrewrite one does). You can change the ROOT webapp to be cross-context by addint crossContext="true" to webapps/ROOT/META-INF/context.xml.
Finally, you should really stop putting <Context> elements in server.xml: leaving them in there basically means you need to restart Tomcat in order to change your webapp deployments.
After the comments I come do this possible conclusion:
I think you are mixing the concepts of a reverse proxy with cross-context. Cross-context is method to share data between two web-applications within the same application server. A reverse-proxy like 'Apache http' can rewrite a url to pass it to a certain server behind it, effectively hiding any unwanted parts or performing other operations like load-balancing.
The infrastructure would be: client --> reverse proxy --> application server