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
