Please find my comments in line.. On Mon, Jul 1, 2013 at 1:57 PM, Ruwan Yatawara <[email protected]> wrote:
> Thanks Udayanga! > > However, when looking through the Syanpse+Axis code, i came to the > understanding that, transport validation is done via 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 > True transport validation always happens at axis level. However for a typical incoming request, Axis2 is what responsible for dispatching request to Synapse mediation layer , NOT the other way around.. Problem is each proxy service has a unique axis2 service instance at runtime , but APIs and main sequence do not (they have one service instance '__SynapseService' ie:- n:1 mapping ). > 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). > For reasons above which i mentioned ,we can't consider APIs as a pure service in axis2 terms, rather an extension of 'main'. For instance calling #setExposedTransports,etc will affect 'main' sequence as well as all APIs equally. > > 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. But if it is, I > can achieve my desired outcome in Syanpse level itself, without having to > do any changes to Axis. > > You don't have to modify Axis2 layer anyway. Also converting Synapse APIs into proper axis services may also defeat the purpose of Restful API's (of which it was first envisioned to skip axis2 layer entirely to give more leverage). Regards Udayanga Please feel free to weigh in your thoughts. > > Cheers, > Ruwan Yatawara > > > On Fri, Jun 28, 2013 at 7:36 PM, Udayanga Wickramasinghe < > [email protected]> wrote: > >> Hi, >> This would work ok but i think there is a slight problem. Each time >> a message is received by a non-allowed transport of an API , it will arrive >> until the synapse mediation layer and will endup in the 'main' sequence >> (because respective API has rejected it) . Because such request is intended >> for a proper API ( But just not passing through allowed transport channel) >> user might not want it to go through the 'main' sequence. Hence you may >> need to handle 'dropping' off the message gracefully from the API . >> However APIs are not Axis services ,therefore i think this runtime >> checking is not as effective as using AxisService#setExposedTransports >> method (used in ProxyServices)... >> >> Regards >> Udayanga >> >> >> >> On Fri, Jun 28, 2013 at 5:18 AM, Ruwan Yatawara <[email protected]> wrote: >> >>> Hi All, >>> >>> We have a requirement to introduce access restrictions to APIs based >>> transport type. As it is done for proxy services, we wish to introduce a >>> "transport" attribute based on which, access to the API will be deflected >>> or approved. >>> >>> From what i observed, we may introduce a condition in canProcess() >>> method of API class, to validate the inTransport of message context against >>> the configured list of transports. But is it the correct way to achieve >>> this? >>> >>> Pls. find attached sample API xml. >>> >>> Your advise on this regard would be highly appreciated. >>> >>> >>> >>> Thanks and Regards, >>> >>> Ruwan Yatawara >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> >> -- >> http://www.udayangawiki.blogspot.com >> > > -- http://www.udayangawiki.blogspot.com
