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
