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. > +1. Adding meaningful message to response would be helpful when we return 403. Thanks, Sanjeewa. > > 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 > > -- * * *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
