Vulnerability in EPiServer.Forms
404 NonFound Handler plugin is not working for some of the redirects that we set up, while it works for some others. Is there a limit on total redirects that we can set up? There are about 428 URLs we have setup
Following are not working:
Also, how do I set wild card for these?
Are you sure the one that don't work don't have active pages on those URLs? It's a 404 handler so it only works when a 404 is served e.g. no content in Optimizely on that route
Also there's a section on the docs that explains wildcards https://github.com/Geta/geta-notfoundhandler
@Scott Reed, When you say active pages, how do I deactivate a page in Optimizely/Epi? So this 404 handler won't do redirects? Is there a good plugin for CMS 12 (.NET 6) that is a redirect manager?
This is a good plugin to do redirects, but it will only redirect urls that does not exist in the CMS. If you have a page somewhere with the same url as you're trying to redirect, it won't, because pages have priority.
We use the Geta Notfound Handler on all our CMS 12 builds and it does a fantastic job. Yes it will not perform a redirect if the content exists and it is published. The question is why would you want a redirect if the content exists and is published? Surely in this case the content is undesired and should be removed or unpublished. If the page is expired, it will return a 404 and the Geta NotFound handler redirect will work.
You can expire a page by following these steps:
Then your redirects in the Geta Notfound handler will work.
@Mark Stott That is very helpful. Can you also please provide guidance on when to use Shortcuts, the functionality provided by Epi/Optimizely within the page properties in CMS
We experienced an issue with this notfoundhandler, where we got the following error message in the log:System.InvalidOperationException: The response cannot be cleared, it has already started sending.The bug could not be reproduced on localhost which seemed strangely enough to be because of the VS Plugin / Feature BrowserLink, which seemed to delay the Response.HasStarted from being set to true. Deactivating BrowserLink made the error surface in localhost aswell. Turns out that there was a middleware that we used in our pipeline that caused this issue with Response.HasStarted being set to true, and we had to move the Geta not found handler and the "opti not found handler" after/below this middleware. Just writing here if anyone else runs into the same issue.The middleware that messed things up was: app.UseStatusCodePagesWithReExecute(...), which maybe is not so strange after all since this middleware starts a new request pipeline.Moving the notfound handlers after app.UseStatusCodePagesWithReExecute solved our problem.