AFIU you do not need to handle sending 403 etc.. in API dispatch logic. Just return false in canProcess() method.
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
