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