[Apiman-user] 回覆: Is it possible blocking request after request body parsing?

Fri Jun 15 05:13:06 EDT 2018

Dear Marc

Sorry that I tried to reproduce the issue in my local test environment however I can't get body content anymore without ticking the stateful payload introspection option.
Besides I just enable 1 policy in order to simplify the test.
If you need more information, please let me know.
Thanks for your help.

________________________________
寄件者: Marc Savy <marc.savy at redhat.com>
寄件日期: 2018年6月12日 下午 10:28
收件者: 林 柏廷
副本: Eric Wittmann; apiman-user at lists.jboss.org
主旨: Re: [Apiman-user] Is it possible blocking request after request body parsing?

I haven't been able to reproduce this. Could you please provide a bit
more information so I can debug this.

1. What is your policy chain
2. Can you provide a skeleton policy that reproduces the issue where
you say you are able to get a parsed entity without ticking the
appropriate box in the UI?

On 30 April 2018 at 02:16, 林 柏廷 <btlin1025 at hotmail.com> wrote:
> Thanks for your information.
> I'll enable this option for parsing request body.
>
> ________________________________
> 寄件者: Marc Savy <marc.savy at redhat.com>
> 寄件日期: 2018年4月26日 下午 07:36
> 收件者: Eric Wittmann
> 副本: 林 柏廷; apiman-user at 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 at redhat.com> 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 at hotmail.com> 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 at redhat.com>
>>> 寄件日期: 2018年4月25日 下午 08:15
>>> 收件者: 林 柏廷
>>> 副本: apiman-user at 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 at hotmail.com> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20180615/1d3c8919/attachment.html 