synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruwan Yatawara <>
Subject Re: Introducing transport level (HTTPs etc.) access restriction to APIs
Date Mon, 01 Jul 2013 17:57:45 GMT
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 case there isn't an attached
service, Synapse will specify the default "__SynapseService" as the

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. But if it is, I can
achieve my desired outcome in Syanpse level itself, without having to do
any changes to Axis.

Please feel free to weigh in your thoughts.

Ruwan Yatawara

On Fri, Jun 28, 2013 at 7:36 PM, Udayanga Wickramasinghe <> 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 <> 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:
>> For additional commands, e-mail:
> --

View raw message