It can be done by setting HTTP_SC property
API-M's main sequence section.
<payloadFactory>
<format>
<am:fault xmlns:am="http://wso2.org/apimanager";>
<am:code>404</am:code>
<am:type>Status report</am:type>
<am:message>Not Found</am:message>
<am:description>The requested resource (/$1) is
not available.</am:description>
</am:fault>
</format>
<args>
<arg expression="$axis2:REST_URL_POSTFIX"/>
</args>
</payloadFactory>
<property name="HTTP_SC" value="404" scope="axis2"/>
<property name="RESPONSE" value="true"/>
<header name="To" action="remove"/>
<property name="NO_ENTITY_BODY" scope="axis2"
action="remove"/>
<send/>
<drop/>
On Fri, Jul 5, 2013 at 12:16 PM, Afkham Azeez <[email protected]> wrote:
>
>
>
> On Fri, Jul 5, 2013 at 12:04 PM, Miyuru Wanninayaka <[email protected]>wrote:
>
>> AFIU you do not need to handle sending 403 etc.. in API dispatch logic.
>> Just return false in canProcess() method.
>>
>
> How does that automatically set the HTTP status code to 403 or 302?
>
>
>>
>> You can write a synapse config to handle messages not hitting to any
>> resource in main sequence. Check API-M's main sequence.
>>
>>
>> On Fri, Jul 5, 2013 at 10:53 AM, Ruwan Yatawara <[email protected]> wrote:
>>
>>> On Fri, Jul 5, 2013 at 10:51 AM, Sanjeewa Malalgoda
>>> <[email protected]>wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jul 5, 2013 at 10:27 AM, Afkham Azeez <[email protected]> wrote:
>>>>
>>>>> In addition to 403, it would also be nice to support a 302. Sometimes,
>>>>> if you access via the wrong transport, it is better to redirect to the
>>>>> URL
>>>>> containing the correct transport. So, we can have an additional property
>>>>> which will specify whether a 403 or 302 has to be returned in the case of
>>>>> the request coming on an unavailable transport.
>>>>>
>>>> +1. When we return 302 we need to point to where that document moved
>>>> (if we have enough information). If we tried google.com it will return
>>>> something like this.
>>>>
>>>> < HTTP/1.1 302 Found
>>>> < Location: http://www.google.lk/
>>>>
>>>>
>>>> <TITLE>302 Moved</TITLE></HEAD><BODY>
>>>> <H1>302 Moved</H1>
>>>> The document has moved
>>>> <A HREF="http://www.google.lk/";>here</A>.
>>>> </BODY></HTML>
>>>>
>>>
>>> @Sanjeewa and @Azeez, I'm working on addressing both issues.
>>>
>>> Thanks for the feedback.
>>>
>>>
>>>>
>>>> So smart client apps will do second call to moved location(here
>>>> www.google.lk/ ) and get response from there. We can use same here.
>>>>
>>>>
>>> Thanks,
>>>> Sanjeewa.
>>>>
>>>>>
>>>>> Azeez
>>>>>
>>>>>
>>>>> On Fri, Jul 5, 2013 at 10:11 AM, Ruwan Yatawara <[email protected]>wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I was able to achieve $subject using an alternate method.
>>>>>>
>>>>>> Now, the transport validation is done at the API level, and if the In
>>>>>> inTransport in the message context does not match any of the transports
>>>>>> listed in the API configuration, a property will be set in the Syanpse
>>>>>> MessageContext, which in turn will be copied on to the Axis2
>>>>>> MessageContext. Ultimately at the time of fabricating the response, this
>>>>>> property will be checked, if it exists, a 403 forbidden response will be
>>>>>> sent as the response.
>>>>>>
>>>>>> Thanks,
>>>>>> Ruwan Yatawara
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 3, 2013 at 9:32 AM, Ruwan Yatawara <[email protected]>wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I did a rough implementation of the method I communicated in the
>>>>>>> previous mail (of making a pseudo-service out of the each rest API), and
>>>>>>> the concept "works" but it kind of looks like a "hack" at the end of the
>>>>>>> day.
>>>>>>>
>>>>>>> I've listed down a few reasons, as to why this approach seems this
>>>>>>> way.
>>>>>>>
>>>>>>> 1. The barrier between API and Proxy Service now seems murkier than
>>>>>>> ever
>>>>>>> 2. When going by this approach APIs need to be accessed with a
>>>>>>> "/services/<CONTEXT>" url pattern.
>>>>>>> 3. I had to re-implement the proxy service instantiating methods
>>>>>>> leaving out most of the logic, in-order to create pseudo-services
>>>>>>> 4. We will not be able to have a Rest API and Proxy Service with the
>>>>>>> same name, at a given point of time (Since the AxisConfiguration will
>>>>>>> maintain an entry for the pseudo-service created in the API's stead)
>>>>>>> 5. Since, in the code "context" value specified in the URL will be
>>>>>>> used to look up the Service. API name and Context needs to be the same.
>>>>>>>
>>>>>>> What do you all think? What would be the best way to achieve
>>>>>>> $subject?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Ruwan Yatawara
>>>>>>>
>>>>>>> Ruwan Yatawara
>>>>>>>
>>>>>>> Software Engineer,
>>>>>>> WSO2 Inc.
>>>>>>> lean . enterprise . middleware
>>>>>>>
>>>>>>> email : [email protected]
>>>>>>> mobile : +94 77 9110413
>>>>>>> www: :http://wso2.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jul 1, 2013 at 11:15 PM, Ruwan Yatawara <[email protected]>wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> We are trying to introduce transport level access restrictions to
>>>>>>>> APIs. As is already there in Proxy-Services, we seek to introduce a
>>>>>>>> transport attribute to the API configuration and filter API access via
>>>>>>>> same.
>>>>>>>>
>>>>>>>> However when looking through the Syanpse code, i came to the
>>>>>>>> understanding that, transport validation is done via the axis2 code
>>>>>>>> (It's
>>>>>>>> the same block of code) for both Proxy Services and APIs. Before
>>>>>>>> dispatching a call to Axis2, Synapse will verify whether the message
>>>>>>>> context includes a service. When it comes to APIs, in which case there
>>>>>>>> isn't an attached service, Synapse will specify the default
>>>>>>>> "__SynapseService" as the service.
>>>>>>>>
>>>>>>>> Because of this, when it comes down to the Axis level, Proxy
>>>>>>>> Service and Rest API calls will both be treated as services (since both
>>>>>>>> have services assign to them). When Service#getExposedTransports
>>>>>>>> method is
>>>>>>>> called, whilst the proxy service will relay back transports configured
>>>>>>>> for
>>>>>>>> that "specific" service, Rest APIs would always return the exposed
>>>>>>>> transports for the "default" service (which are always HTTP & HTTPS).
>>>>>>>>
>>>>>>>> As a workaround for this I was thinking, maybe we can constitute
>>>>>>>> some sort of "Pseudo-Service" (Since it is anyhow being treated at Axis
>>>>>>>> level as a Service) out of each Rest API, and maintain a Deployer that
>>>>>>>> will
>>>>>>>> set/update parameters like "ExposedTransports" that may in turn be
>>>>>>>> accessed
>>>>>>>> via Axis.
>>>>>>>>
>>>>>>>> I'm not entirely sure if this is the right thing to do.
>>>>>>>>
>>>>>>>> Please feel free to weigh in your thoughts.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Ruwan Yatawara
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Afkham Azeez*
>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com
>>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>>> * <http://www.apache.org/>**
>>>>> email: **[email protected]* <[email protected]>* cell: +94 77 3320919
>>>>> blog: **http://blog.afkham.org* <http://blog.afkham.org>*
>>>>> twitter:
>>>>> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>>>>> *
>>>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>>>>> *
>>>>> *
>>>>> *Lean . Enterprise . Middleware*
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> [email protected]
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *
>>>> *
>>>> *Sanjeewa Malalgoda*
>>>> WSO2 Inc.
>>>> Mobile : +94713068779
>>>>
>>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>>> :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Miyuru Wanninayaka
>> Technical Lead
>> WSO2 Inc. : http://wso2.com
>>
>> Mobile : +94 77 209 9788
>> Blog : http://miyurudw.blogspot.com
>> Flickr : http://www.flickr.com/photos/miyuru_daminda
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; http://www.apache.org/
> * <http://www.apache.org/>**
> email: **[email protected]* <[email protected]>* cell: +94 77 3320919
> blog: **http://blog.afkham.org* <http://blog.afkham.org>*
> twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Miyuru Wanninayaka
Technical Lead
WSO2 Inc. : http://wso2.com
Mobile : +94 77 209 9788
Blog : http://miyurudw.blogspot.com
Flickr : http://www.flickr.com/photos/miyuru_daminda
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
