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
