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> 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
