Forum Discussion
BaaDf00d_300951
Nimbostratus
NimbostratusASM redirect on api call, does not generate a redirect for a user
Hi,
Looking to solve a problem with a ASM Policy. Where by i force it to redirect the user to a custom page explaining what has happened to their request. But when it blocks a background call (api service call) the browser page that generated the request is not enlightened by this. This is by no means a simple thing to resolve but am looking for the best practice solution to the issue that redirecting to a custom page does not handle all cases.
I thought maybe handling the ASM response in Irule might enable me to alter the response and deliver a different payload that would enable me to redirect to the custom page.
How do other people handle this background service call blocking issue if someone manages to incorrectly get blocked in a background process.
Thanks
So I have sorted out a solution to this albeit not very graceful. I could not get a popup of any type to display. What i did, in the custom response, Dropped a cookie, on the client machine, than on the next request read the cookie with an IRUle and deleted it, forcing a redirect to the block page at that point in time, and passing the support ID through the cookie i had created.
Not very graceful, as it doesnt redirect to the support page instantly, but it shows the support page afterwards. Bit of a hack, issue is that each request redirected by the Location: 302 redirect that works successfully does not delete the cookie, so the support page needs to also delete the cookie to stop repeated redirects.
irule:
when HTTP_REQUEST { set block_is_set [HTTP::cookie exists "Block-Cookie"] if {$block_is_set == 1} { set support_id [HTTP::cookie value "Block-Cookie"] HTTP::cookie remove "Block-Cookie" HTTP::respond 302 noserver Location "https://supportpageDomain/URLPath?support_id=$support_id" Connection close Set-Cookie "Block-Cookie=;expires=Thu, 01 Jan 1970 00:00:00 GMT" } }Custom Response Header:
HTTP/1.1 302 OK Cache-Control: no-cache Pragma: no-cache Location: https://supportpageDomain/URLPath?support_id=<%TS.request.ID()%> set-cookie: Block-Cookie=<%TS.request.ID()%>; Path=/; HttpOnly; Secure
youssef1Cumulonimbus
Hi,
unfortunately this kind of problem is fairly recurrent, if I understand correctly one of your call API is blocked and you expect the user to be redirected. However an API Call / REST, it's not a standard web request. the query to a well-defined format and the expected response also... So if you have a block with a redireciton on the answer of your CALL API, it will not be interpreted. because the context is differente.
If you want to manage this kind of problem (AJAX CALL), you have to do it on the client side (application). I did a similar job by putting a javascript client side that allowed to reload the whole page when I had a very specific REST return.
I advise you to manage this behavior in application side...
Regads,
BaaDf00d_300951So I have sorted out a solution to this albeit not very graceful. I could not get a popup of any type to display. What i did, in the custom response, Dropped a cookie, on the client machine, than on the next request read the cookie with an IRUle and deleted it, forcing a redirect to the block page at that point in time, and passing the support ID through the cookie i had created.
Not very graceful, as it doesnt redirect to the support page instantly, but it shows the support page afterwards. Bit of a hack, issue is that each request redirected by the Location: 302 redirect that works successfully does not delete the cookie, so the support page needs to also delete the cookie to stop repeated redirects.
irule:
when HTTP_REQUEST { set block_is_set [HTTP::cookie exists "Block-Cookie"] if {$block_is_set == 1} { set support_id [HTTP::cookie value "Block-Cookie"] HTTP::cookie remove "Block-Cookie" HTTP::respond 302 noserver Location "https://supportpageDomain/URLPath?support_id=$support_id" Connection close Set-Cookie "Block-Cookie=;expires=Thu, 01 Jan 1970 00:00:00 GMT" } }Custom Response Header:
HTTP/1.1 302 OK Cache-Control: no-cache Pragma: no-cache Location: https://supportpageDomain/URLPath?support_id=<%TS.request.ID()%> set-cookie: Block-Cookie=<%TS.request.ID()%>; Path=/; HttpOnly; Secure
fatotov31I have thus come up with a solution, although a crude one. No popup of any kind would show for me. What I entered as a custom answer was I dropped a cookie on the client computer, read it with an IRUle during the subsequent request, and then destroyed it, forcing a redirect to the block page and allowing the support ID to be sent through the cookie I had set. Not very smooth because the assistance page isn't displayed right away but rather appears later. It's a bit of a hack because each request that is properly htaccess redirect by the Location: 302 redirect leaves the cookie behind; thus, the help page must likewise remove url.