I use JSF 2.1.7 Mojarra.
If I write an incorrect URL (a page that doesn't exist) in the address bar of the browser, in order to test that I'm redirected to my custom error page for http error 404, I get instead the following exception (error 500):
com.sun.faces.context.FacesFileNotFoundException
I've found that this is a bug. See the following issue in Jira:
http://java.net/jira/browse/JAVASERVERFACES-1762
And that it has been already fixed (modifying the code of some JSF classes). See:
http://java.net/projects/mojarra/lists/commits/archive/2010-12/message/18
But I haven't found any patch.
Where can I get the patch that fix this bug? Is it possible to get or do I have to override the JSF code myself?
Thank you very much.
I suppose JSF is trying to be independent of Servlets/HTTP with this exception. I just catch it in a filter:
try {
chain.doFilter(request, response);
} catch (FacesFileNotFoundException e) {
response.sendError(404, e.getMessage());
}
Related
I am using SpringDoc 1.4.3 for swagger. I have added the below configuration to disabled the petstore URLs in application.yml
Configuration
springdoc:
swagger-ui:
disable-swagger-default-url: true
tags-sorter: alpha
operations-sorter: alpha
doc-expansion: none
but when I hit the https://petstore.swagger.io/v2/swagger.json in explore text box, it is still showing me the petsore URLs as shown in the below image.
Swagger Image
Already tested and validated thanks to the following feature support:
https://github.com/springdoc/springdoc-openapi/issues/714
Just use, the following property:
springdoc.swagger-ui.disable-swagger-default-url=true
For those if the suggested property setting did not work, clear the browser cache and reload the URL. The property setting DOES WORK. Wasted 2 hours to figure it out.
springdoc:
swagger-ui:
disable-swagger-default-url: true
The only way I got around this was by adding a SwaggerConfig page [tutorial here] and changing to OAS_3 and saving, and then you can either change it to something else after.
return new Docket(DocumentationType.OAS_30)
It just seems like Swagger is keeping a cache or something, but saving a configured OAS_3 seems to let Swagger know to stop using the default.
In my case, I had an incorrectly-defined servlet filter - I was missing a 'return;' statement. This caused the filter chain to not be processed properly, and some of the Swagger requests got borked.
Check to see if you have the following condition:
#Component
public class MyFilter implements Filter {
#Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
if (some condition) {
chain.doFilter(request, response);
return; /**** Don't forget this line! ****/
}
... more logic ...
chain.doFilter(request, response);
}
}
Set below property, this will disable Swagger OpenApi 3 UI module
springdoc.api-docs.enabled=false
We having a specific problem in using Wicket 7.10, creating an Ajax-Response with multiple entries.
In our application, we are using onRequestHandlerResolved to do some initialization stuff and onRequestHandlerExecuted to save changes done on our data during requestHandlerExecutor.execute().
For this purpose, we have created an own AbstractRequestCycleListener which overwrites both methods and calls our specific code.
RequestCycle:
private void execute(IRequestHandler handler)
{
try
{
listeners.onRequestHandlerResolved(this, handler);
requestHandlerExecutor.execute(handler);
listeners.onRequestHandlerExecuted(this, handler);
}
catch (RuntimeException e)
{
}
}
Our problem is, that an Exception thrown in onRequestHandlerExecuted after requestHandlerExecutor.execute() has already created an ajax-response creates an invalid response:
Wicket.Ajax: Wicket.Ajax.Call.failure: Error while parsing response: Error: Invalid XML:
<?xml version="1.0" encoding="UTF-8"?>
<ajax-response>
<!-- Result of requestHandlerExecutor.execute() -->
</ajax-response>
<ajax-response>
<!—Redirect to specific Exception Page, result of onRequestHandlerExecuted -->
<redirect>
<![CDATA[./wicket/bookmarkable/our.package.ExceptionPage?locale=en]]>
</redirect>
</ajax-response>
To solve our problem, we tried to clear the existing Response during Exception in onRequestHandlerExecuted (RequestCycle.get().getResponse().reset()), but we are not able to clear the Response, created in requestHandlerExecutor.execute(), because Wicket uses HeaderBufferingWebResponse by default which did not allow to reset already created Response in encapsulated ServletWebResponse. Calling reset in HeaderBufferingWebResponse instead throws an IllegalStateException.
We think that the problem came from ServletWebResponse which simply adds multiple ajax-response entries to the HttpServletResponse which results in the mentioned, invalid XML.
ServletWebResponse:
#Override
public void sendRedirect(String url)
{
try
{
if (webRequest.isAjax())
{
/*
* usually the Ajax-Location header is enough and we do not need to the redirect url
* into the response, but sometimes the response is processed via an iframe (eg
* using multipart ajax handling) and the headers are not available because XHR is
* not used and that is the only way javascript has access to response headers.
*/
httpServletResponse.getWriter().write(
"<ajax-response><redirect><![CDATA[" + url + "]]></redirect></ajax-response>");
}
else { }
}
catch (IOException e) { }
}
How we could handle the problem when throwing an Exception in onRequestHandlerExecuted? And how is it possible, that code run after requestHandlerExecutor.execute(), redirects correctly to an Exception page?
How we can run specific code, after the request has been processed, is there maybe another way instead of overwriting onRequestHandlerExecuted?
For each Ajax request Wicket executes two request handlers:
ListenerInterfaceRequestHandler
AjaxRequestHandler
I assume your #onRequestHandlerExecuted is failing after the second one. This might be too late since the response is already generated and written.
You could check:
why does your listener fail after anything else has happened already?
what do you want your application to do when your listener fails?
can't the listener fail after the first handler already? why wait any longer?
This question is about the implementation of the Authorization Code flow using Owin in Asp.net Wep Api.
I was trying to handle some error that might happen on my AuthorizationCode code creation. Apparently I can't redirect my self to the Client Redirect URI with he correct error code which is "server_error"
The following is my code :
private static void CreateAuthorizationCode(AuthenticationTokenCreateContext context)
{
try
{
//Some Code to create and save the AuthorizationCode that can throw an Exception
context.SetToken(code);
}
catch (Exception ex)
{
logger.Fatal(ex);
var redirectUri = GetRedirectUri();
var redirectLocation = string.Format("{0}?code={1}", redirectUri, "server_error");
context.Response.Redirect(redirectLocation);
}
}
But I get redirected by the framework to the redirect Uri with https://redirecturi?error=unsupported_response_type !
Is this a normal behavior ? Or maybe there is any other way to handle those kind of scenario and set by myself the error code !?
PS : I created an issue in Github about that : https://github.com/aspnet/Security/issues/375 no answer so far !
Thank you.
Is this a normal behavior ? Or maybe there is any other way to handle those kind of scenario that I'm missing?
Normal, I dunno. But expected, definitely: when using an IAuthenticationTokenProvider, you're not supposed to alter the HTTP response.
Why there is not way to set by myself the error using the AuthenticationTokenCreateContext object like context.SetError("my_error") ?
Unlike the ValidateAuthorizeRequest notification, it hasn't been designed to allow you to return an error.
Sadly, there's no way to return a server_error response from an IAuthenticationTokenProvider, since OAuthAuthorizationServerHandler will always use unsupported_response_type if you don't provide an authorization code: https://github.com/jchannon/katanaproject/blob/master/src/Microsoft.Owin.Security.OAuth/OAuthAuthorizationServerHandler.cs#L204
FYI, this is something we fixed recently in AspNet.Security.OpenIdConnect.Server (a fork of the OAuth2 authorization server shipped with Katana 3): https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/issues/112#issuecomment-125040925. If your custom code returns a null authorization code, a server_error response will be automatically returned to the client application.
I am attempting to migrate an application from JSF 1.2 to JSF 2.1. The code below worked in the 1.2.
I am using PrettyFaces 3.3.3, MyFaces 2.1.
in pretty-config.xml:
<url-mapping id="seSite">
<pattern value="/sites/#{seViewChooserBean.urlSiteType}/#{seViewChooserBean.siteId}"/>
<view-id value="#{seViewChooserBean.getSiteViewId}"/>
</url-mapping>
<url-mapping id="seSiteProps">
<pattern value="/sites/#{sePropsBean.urlSiteType}/#{sePropsBean.siteId}/properties"/>
<view-id value="/pages/se/site/props.xhtml"/>
<action>#{sePropsBean.init}</action>
</url-mapping>
I have a request with URL: http://example.com/myapp/sites/object/309847
This request successfully matches the url mapping id "seSite" and getSiteViewId is invoked on seViewChooserBean and returns the result "pretty:seSiteProps". I have debugged and confirmed this. For your reference this is the bean code for ViewChooserBean.java:
public String getSiteViewId() {
if (siteType == SiteType.TYPE) {
// redirect to tag list view
initSiteBean("seTagListBean", TagListBean.class);
return "pretty:seTagList";
}
else {
// redirect to site properties view
initSiteBean("sePropsBean", PropertiesBean.class);
return "pretty:seSiteProps";
}
}
After that prettyfaces then attempts to forward to the new view id seSiteProps but the new generated URL is not processed by pretty faces because (from the logs): "Request is not mapped using PrettyFaces. Continue."
So I get 404 response for URL http:://example.com/myapp/sites/object/309847/properties.
Note that this url match to view id seSiteProps.
I have debugged this up into the pretty faces filter and discovered the following:
After the initial request for http://example.com/myapp/sites/object/309847, the DynaviewEngine.processDynaView is invoked and generates the correct target url http:://example.com/sites/object/309847/properties and forwards via faces request.
Then, with a breakpoint in PrettyFilter.doFilter() I observed the following:
In PrettyFilter.doFilter() method: isUrlMappingForward(req) returns false, therefore request is not processed by prettyfaces. Why??
// isUrlMappingForward returns false. The request has url http:://example.com/myapp/sites/object/309847/properties on it.
if (!isUrlMappingForward(req))
{
mapping = getConfig().getMappingForUrl(url);
}
Also, note that if I put the request http:://example.com/myapp/sites/object/309847/properties directly in the browser the page IS processed by prettyfaces and isUrlMappingForward(req) returns true and it loads correctly in the browser.
I was thinking I've missed something obvious here as the problem hasn't been reported elsewhere as far as I can tell. Any help is greatly appreciated. Thanks.
Brett
Actually I'm very surprised that returning PrettyFaces navigation strings from dynaview methods ever worked. This isn't documented anywhere and I doubt that this has been tested in detail. So basically you are using the dynaview feature in an very weird way.
So I recommend to return plain JSF view IDs instead which should work fine. See the documentation for details:
http://ocpsoft.org/docs/prettyfaces/3.3.3/en-US/html/Configuration.html#config.dynaview
i'm trying to send back a simple error message as Json, with the HTTP code as 404.
So i started out writing my own IExceptionFilter that checks to see the exception. To keep this simple, if the exception throw is of type ResourceNotFoundException then i set the code to 404. Otherwise everything else if 500.
Now, the problem is .. the default IIS7 404 error message is returned :( my code is called .. but it seems to bypass it (later on in the pipeline)...
is there some trick i need to do?
do I need a custom error handling (in the web config) to be turned on or something?
Edit:
I'm trying to do what twitter does. Their Http Response Code documentation shows / explains some examples how they handle 404's, etc.. and i'm wanting to do that in my MVC app.
Edit 2:
The code i've done is listed here, for anyones reference :)
When you are handling your exception, are you setting ExceptionHandled to true?
Here's a quick example...
HandleException(ActionExecutedContext filterContext)
{
Exception exception = filterContext.Exception;
//Check if our exception has been handled.
if (filterContext.ExceptionHandled == false)
{
//Do your exception stuff
filterContext.Result = YourExceptionMessageAsAnActionResult();
//Set it as null.
filterContext.ExceptionHandled = true;
filterContext.HttpContext.Response.Clear();
}
}