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 >> > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
