Forum Discussion
Blocking Response Page seems to be blocked
We've set up a custom blocking response page on our site but it seems to be blocked when an illegal request is detected. The custom page is a contact form that, when filled by the client, enables us to contact him/her to solve the issue. The page is in the Allowed URLs list. The blocking response page is on the same server/domain as the monitored website.
The URI is something like https://mydomain.com/errorpage.php
Any idea on how to tell the F5 to NEVER BLOCK this URL?
3 Replies
- crodriguezRet. Employee
When a request is blocked by ASM, that happens before the connection is ever proxied to the back end server. You can configure a custom blocking response in ASM so that, when ASM does block a request, the client is redirected to a different location, such as your custom PHP form. See this article here: https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-11-5-0/25.html
Although it's for 11.5, you can check the equivalent on later releases.
Hi Ghislain,
I'm using a layered approach for my violation pages.
- If an violation occours somewhare on the page, the request will be redirected to the landing page, with a query string appended containing an b64encoded SupportID (e.g.
)./default.html?RequestID=[b64encode [ASM::support_id]] - If a violation occours and a the RequestID parameter is present, the violation response will not trigger the HTTP-Redirect to the landing page again. Instead it will directly serve a HTTP Err403 response to the client that the request was blocked.
This behavior gives us a good user experience (no explicit error messages), still allows easy troubleshootings (via embedded query string information) and implements a decent protection for redirect loops, which may occour if the redirected request to the error page would trigger a violation again (e.g. disallowed/misconfigured user-agents, etc.).
Cheers, Kai
- If an violation occours somewhare on the page, the request will be redirected to the landing page, with a query string appended containing an b64encoded SupportID (e.g.
- Abdessamad1
Cirrostratus
Another solution to this loop problem would be to remove all elements coming from the initial request that could cause the violation on the blocking response page. These could be in the Referer header or in the cookies.
when HTTP_REQUEST { if { [HTTP::uri] starts_with "/my-blocking-response-page" }{ if { [HTTP::header exists Referer] }{ HTTP::header remove Referer } foreach cookiename [HTTP::cookie names] { switch -glob $cookiename { "a-cookie-I-want-to-keep-1" - "a-cookie-I-want-to-keep-2" {} default { HTTP::cookie remove $cookiename } } } } }
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com