Hi all, I would like to customize a policy, which parses the request body and blocks the request in case. in http://www.apiman.io/latest/developer-guide.html 4.2.1.2 IData policy, it describes: The request or response body will not begin streaming before the corresponding doApply has been called, however, it is still possible to interrupt the conversation during the streaming phase by signalling doFailure or doError. When I trace the transformation-policy source code, doApply() executes before getRequestDataHandler() which matches the description. In doApply() I can blocks the request via chain.doFailure() however I have no idea how to interrupt/block request in getRequestDataHandler(). Besides, I found following mail group which is similar to my question. Eric also points it's possible to parse the body before apply in request: *On Thu, Feb 2, 2017 at 10:31 PM, Eric Wittmann <* *eric.wittmann at redhat.com <http://redhat.com>> wrote:* * The bottom line here is that you cannot return a Policy Failure (or* * customize it) based on information in the response body. The response is* * streamed from the back-end to the client, and at the time streaming begins,* * the response code and HTTP headers have already been sent.* * It sounds to me like you're asking for a feature where you can parse* * the response body *before* the policy's "apply" method is invoked. we have* * such a feature for requests, but not for responses. I suspect core changes* * to apiman would be required to enable that. It seems like a reasonable* * request to me, as long as users of the feature understand the performance* * and memory requirements of enabling it.* * -Eric* Thanks for any comments in advance. Kind Regards BT _______________________________________________ Apiman-user mailing list Apiman-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-user

Dear Eric Thanks for your helpful information. I can get request body with IPolicyContext object. Besides, you also mentioned *enable this on a per-API basis in the apiman UI.* Is It "Enable stateful request payload insepction" in API implementation tab? I'm wondering because I didn't enable this option but can still get the request body in doApply() with IPolicyContext. What is the difference if I enable this option? Thanks Regards ------------------------------ *寄件者:* Eric Wittmann <eric.wittmann(a)redhat.com&gt; *寄件日期:* 2018年4月25日 下午 08:15 *收件者:* 林 柏廷 *副本:* apiman-user(a)lists.jboss.org *主旨:* Re: [Apiman-user] Is it possible blocking request after request body parsing? Yes there is a feature where apiman will parse the request BEFORE applying the policies. This will make the HTTP request body available to all policies in the chain, should they need them. You can enable this on a per-API basis in the apiman UI. When this feature is enabled, your custom policy can access the request body as an object found in the IPolicyContext object. For example: Object payload = context.getAttribute("apiman.request-payload"); The type of thing that you get depends on the API's endpoint type. The endpoint type might be JSON, XML, or SOAP. I think it might be possible to have some other kind of endpoint type, but those three are handled by the request body parser feature. Here is what you'll get as that payload object, depending on endpoint type: JSON - Java Map object as a result of parsing the JSON data using Jackson XML - org.w3c.dom.Document Soap - javax.xml.soap.SOAPEnvelope Anything Else - byte[] So for example, if your endpoint type is XML, then you could do this in your policy implementation (in the doApply() method): org.w3c.dom.Document requestBody = (org.w3c.dom.Document) context.get tAttribute("apiman.request-payload"); And then you could make some decision using the request data and e.g. call doFailure(). Also note - you can *change* the request body at this point as well. For example you could apply a XML Transformation to the w3c Document, resulting in a new w3c Document object, which you could store in the Policy Context (at the same key, obviously). That new document would then get serialized and sent as the request body to the backing API impl. There may be some Content-Length issues if you do that, I can't remember... -Eric On Wed, Apr 25, 2018 at 1:29 AM, 林 柏廷 <btlin1025(a)hotmail.com&gt; wrote: Hi all, I would like to customize a policy, which parses the request body and blocks the request in case. in http://www.apiman.io/latest/developer-guide.html 4.2.1.2 IData policy, it describes: The request or response body will not begin streaming before the corresponding doApply has been called, however, it is still possible to interrupt the conversation during the streaming phase by signalling doFailure or doError. When I trace the transformation-policy source code, doApply() executes before getRequestDataHandler() which matches the description. In doApply() I can blocks the request via chain.doFailure() however I have no idea how to interrupt/block request in getRequestDataHandler(). Besides, I found following mail group which is similar to my question. Eric also points it's possible to parse the body before apply in request: *On Thu, Feb 2, 2017 at 10:31 PM, Eric Wittmann <* *eric.wittmann at redhat.com <http://redhat.com>> wrote:* * The bottom line here is that you cannot return a Policy Failure (or* * customize it) based on information in the response body. The response is* * streamed from the back-end to the client, and at the time streaming begins,* * the response code and HTTP headers have already been sent.* * It sounds to me like you're asking for a feature where you can parse* * the response body *before* the policy's "apply" method is invoked. we have* * such a feature for requests, but not for responses. I suspect core changes* * to apiman would be required to enable that. It seems like a reasonable* * request to me, as long as users of the feature understand the performance* * and memory requirements of enabling it.* * -Eric* Thanks for any comments in advance. Kind Regards BT _______________________________________________ Apiman-user mailing list Apiman-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-user

Yes that is the UI option I was referring to. If the request payload is being parsed without that option being set, then there is a bug in the Apiman gateway. I will write up a bug report for that so that @marcsavy can have a look. :) -Eric On Thu, Apr 26, 2018 at 4:36 AM, 林 柏廷 <btlin1025(a)hotmail.com&gt; wrote: > > Dear Eric > > Thanks for your helpful information. > I can get request body with IPolicyContext object. > Besides, you also mentioned enable this on a per-API basis in the apiman > UI. > Is It "Enable stateful request payload insepction" in API implementation > tab? > I'm wondering because I didn't enable this option but can still get the > request body in doApply() with IPolicyContext. > What is the difference if I enable this option? > Thanks > > Regards > > ________________________________ > 寄件者: Eric Wittmann <eric.wittmann(a)redhat.com&gt; > 寄件日期: 2018年4月25日 下午 08:15 > 收件者: 林 柏廷 > 副本: apiman-user(a)lists.jboss.org > 主旨: Re: [Apiman-user] Is it possible blocking request after request body > parsing? > > Yes there is a feature where apiman will parse the request BEFORE applying > the policies. This will make the HTTP request body available to all > policies in the chain, should they need them. > > You can enable this on a per-API basis in the apiman UI. > > When this feature is enabled, your custom policy can access the request > body as an object found in the IPolicyContext object. For example: > > Object payload = context.getAttribute("apiman.request-payload"); > > The type of thing that you get depends on the API's endpoint type. The > endpoint type might be JSON, XML, or SOAP. I think it might be possible to > have some other kind of endpoint type, but those three are handled by the > request body parser feature. > > Here is what you'll get as that payload object, depending on endpoint > type: > > JSON - Java Map object as a result of parsing the JSON data using Jackson > XML - org.w3c.dom.Document > Soap - javax.xml.soap.SOAPEnvelope > Anything Else - byte[] > > So for example, if your endpoint type is XML, then you could do this in > your policy implementation (in the doApply() method): > > org.w3c.dom.Document requestBody = (org.w3c.dom.Document) > context.gettAttribute("apiman.request-payload"); > > And then you could make some decision using the request data and e.g. call > doFailure(). > > Also note - you can *change* the request body at this point as well. For > example you could apply a XML Transformation to the w3c Document, resulting > in a new w3c Document object, which you could store in the Policy Context > (at the same key, obviously). That new document would then get serialized > and sent as the request body to the backing API impl. There may be some > Content-Length issues if you do that, I can't remember... > > -Eric > > > On Wed, Apr 25, 2018 at 1:29 AM, 林 柏廷 <btlin1025(a)hotmail.com&gt; wrote: > > Hi all, > I would like to customize a policy, which parses the request body and > blocks the request in case. > in http://www.apiman.io/latest/developer-guide.html 4.2.1.2 IData policy, > it describes: > The request or response body will not begin streaming before the > corresponding doApply has been called, however, it is still possible to > interrupt the conversation during the streaming phase by signalling > doFailure or doError. > When I trace the transformation-policy source code, doApply() executes > before getRequestDataHandler() which matches the description. > In doApply() I can blocks the request via chain.doFailure() however I have > no idea how to interrupt/block request in getRequestDataHandler(). > Besides, I found following mail group which is similar to my question. > Eric also points it's possible to parse the body before apply in request: > > On Thu, Feb 2, 2017 at 10:31 PM, Eric Wittmann < > eric.wittmann at redhat.com> wrote: > > The bottom line here is that you cannot return a Policy Failure (or > customize it) based on information in the response body. The response is > streamed from the back-end to the client, and at the time streaming > begins, > the response code and HTTP headers have already been sent. > > It sounds to me like you're asking for a feature where you can parse > the response body *before* the policy's "apply" method is invoked. we > have > such a feature for requests, but not for responses. I suspect core > changes > to apiman would be required to enable that. It seems like a reasonable > request to me, as long as users of the feature understand the performance > and memory requirements of enabling it. > > -Eric > > Thanks for any comments in advance. > Kind Regards > BT > > > _______________________________________________ > Apiman-user mailing list > Apiman-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > > _______________________________________________ Apiman-user mailing list Apiman-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-user

Thanks for your information. I'll enable this option for parsing request body. ________________________________ 寄件者: Marc Savy <marc.savy(a)redhat.com&gt; 寄件日期: 2018年4月26日 下午 07:36 收件者: Eric Wittmann 副本: 林 柏廷; apiman-user(a)lists.jboss.org 主旨: Re: [Apiman-user] Is it possible blocking request after request body parsing? Thanks. I'll check it out and report back. On 26 April 2018 at 12:26, Eric Wittmann <eric.wittmann(a)redhat.com&gt; wrote: > Yes that is the UI option I was referring to. > > If the request payload is being parsed without that option being set, then > there is a bug in the Apiman gateway. I will write up a bug report for > that > so that @marcsavy can have a look. :) > > -Eric > > > On Thu, Apr 26, 2018 at 4:36 AM, 林 柏廷 <btlin1025(a)hotmail.com&gt; wrote: >> >> Dear Eric >> >> Thanks for your helpful information. >> I can get request body with IPolicyContext object. >> Besides, you also mentioned enable this on a per-API basis in the apiman >> UI. >> Is It "Enable stateful request payload insepction" in API implementation >> tab? >> I'm wondering because I didn't enable this option but can still get the >> request body in doApply() with IPolicyContext. >> What is the difference if I enable this option? >> Thanks >> >> Regards >> >> ________________________________ >> 寄件者: Eric Wittmann <eric.wittmann(a)redhat.com&gt; >> 寄件日期: 2018年4月25日 下午 08:15 >> 收件者: 林 柏廷 >> 副本: apiman-user(a)lists.jboss.org >> 主旨: Re: [Apiman-user] Is it possible blocking request after request body >> parsing? >> >> Yes there is a feature where apiman will parse the request BEFORE >> applying >> the policies. This will make the HTTP request body available to all >> policies in the chain, should they need them. >> >> You can enable this on a per-API basis in the apiman UI. >> >> When this feature is enabled, your custom policy can access the request >> body as an object found in the IPolicyContext object. For example: >> >> Object payload = context.getAttribute("apiman.request-payload"); >> >> The type of thing that you get depends on the API's endpoint type. The >> endpoint type might be JSON, XML, or SOAP. I think it might be possible >> to >> have some other kind of endpoint type, but those three are handled by the >> request body parser feature. >> >> Here is what you'll get as that payload object, depending on endpoint >> type: >> >> JSON - Java Map object as a result of parsing the JSON data using Jackson >> XML - org.w3c.dom.Document >> Soap - javax.xml.soap.SOAPEnvelope >> Anything Else - byte[] >> >> So for example, if your endpoint type is XML, then you could do this in >> your policy implementation (in the doApply() method): >> >> org.w3c.dom.Document requestBody = (org.w3c.dom.Document) >> context.gettAttribute("apiman.request-payload"); >> >> And then you could make some decision using the request data and e.g. >> call >> doFailure(). >> >> Also note - you can *change* the request body at this point as well. For >> example you could apply a XML Transformation to the w3c Document, >> resulting >> in a new w3c Document object, which you could store in the Policy Context >> (at the same key, obviously). That new document would then get >> serialized >> and sent as the request body to the backing API impl. There may be some >> Content-Length issues if you do that, I can't remember... >> >> -Eric >> >> >> On Wed, Apr 25, 2018 at 1:29 AM, 林 柏廷 <btlin1025(a)hotmail.com&gt; wrote: >> >> Hi all, >> I would like to customize a policy, which parses the request body and >> blocks the request in case. >> in http://www.apiman.io/latest/developer-guide.html 4.2.1.2 IData policy, >> it describes: >> The request or response body will not begin streaming before the >> corresponding doApply has been called, however, it is still possible to >> interrupt the conversation during the streaming phase by signalling >> doFailure or doError. >> When I trace the transformation-policy source code, doApply() executes >> before getRequestDataHandler() which matches the description. >> In doApply() I can blocks the request via chain.doFailure() however I >> have >> no idea how to interrupt/block request in getRequestDataHandler(). >> Besides, I found following mail group which is similar to my question. >> Eric also points it's possible to parse the body before apply in request: >> >> On Thu, Feb 2, 2017 at 10:31 PM, Eric Wittmann < >> eric.wittmann at redhat.com> wrote: >> >> The bottom line here is that you cannot return a Policy Failure (or >> customize it) based on information in the response body. The response >> is >> streamed from the back-end to the client, and at the time streaming >> begins, >> the response code and HTTP headers have already been sent. >> >> It sounds to me like you're asking for a feature where you can parse >> the response body *before* the policy's "apply" method is invoked. we >> have >> such a feature for requests, but not for responses. I suspect core >> changes >> to apiman would be required to enable that. It seems like a reasonable >> request to me, as long as users of the feature understand the >> performance >> and memory requirements of enabling it. >> >> -Eric >> >> Thanks for any comments in advance. >> Kind Regards >> BT >> >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> >> > > > _______________________________________________ > Apiman-user mailing list > Apiman-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user >