RTC Forums

Hello,

I did a simple rtc-based app, that basically is an httpserver with two dataproviders linked.
All is running well, but recently a customer implemented an architecture with:

          (A)                 (B)                   (C)
- client browser > app server > rtc application (mine)

To make a long story short, (A) makes a call to (C) through (B), but probably (C) thinks (or is told to)
that it should reply to (A) (it appears as some sort of triangulation attack in effect), and denies the request.

I was told that I should implement something like this to relax security checks (Java, but just an example):

public class CrossOriginResourceSharingFilter implements ContainerResponseFilter {
    @Override
    public ContainerResponse filter(ContainerRequest request, ContainerResponse response) {
        response.getHttpHeaders().putSingle("Access-Control-Allow-Origin", "*");
        response.getHttpHeaders().putSingle("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
        response.getHttpHeaders().putSingle("Access-Control-Allow-Headers", "content-type");
        response.getHttpHeaders().putSingle("Access-Control-Allow-Headers", "X-Requested-With");
        return response;
    }
    
}

I cannot be more specific since I am not in office as of now. Thanks !

Claudio

It sounds like the situation you've encountered is a security feature known as CORS: Cross-Origin Resource Sharing. 

https://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing

Everything you need to know is on the linked page, above, but just to emphasize, I would not have your RTC data provider return the header Access-Control-Allow-Origin: *

Thanks, Kevin.

However, my services are not exposed to the Intenet, so, are you able to tell me what should I do (in rtc jargon) to permit these calls ?
I am totally lost.

Thank you in advance

Claudio

If you mean that none of your DataProviders recognize this as a valid request, the problem could also be that the AppServer is sending requests with a "HTTP://" prefix in the URI, which isn't what one would normally do when talking to a Web Server. If that is the problem, then setting FixupRequest.RemovePrefix:=True on the TRtcHttpServer component should solve it and give you a clean Request.FileName to work with.

And if you are using RTC Sessions and want to loosen up the way Session IDs are linked to incoming IP addresses, use the OpenSession method with sesNoLock parameter. The default paramere is sesFwdLock, which works with Web Clients as well as Web Proxies, but might not work with custom Servers which don't send the X-FORWARDED-FOR header value in their HTTP requests.

If the problem is related to something else, then I need more information.

To start with, you should log all requests which don't get accepted by your Server. This can easily be done by implementing the OnRequestNotAccepted event on the TRtcHttpServer component. If you want, you can also log requests which do get accepted by implementing the OnRequestAccepted event. The absolute minimum you should write to a LOG file are the TRtcDataServer(Sender).Request.URI and TRtcDataServer(Sender).Request.HeaderText properties.

Best Regards,
Danijel Tkalcec

Hello Danijel,

Thank You all for your quick responses.
Tomorrow morning I will implement logs and will let you know.

(P.S.: no, I'm not using sessions)

Claudio

If the connection is being dropped by the Client or the 3rd-party App Server, because one of them expects to receive speciflc HTTP header values in your response, and the example you have posted above would work from Java, then you can use the code below to prepare the response header in your RTC Server before you start using the "Write" method and send the response out:

var Srv:TRtcDataServer absolute Sender;
begin
   if Srv.Request.Complete then
    begin
     // prepare required HTTP response header parameters
     Srv.Response['Access-Control-Allow-Origin']:='*';
     Srv.Response['Access-Control-Allow-Methods']:='GET, POST, PUT, DELETE';
     Srv.Response['Access-Control-Allow-Headers']:='X-Requested-With';
     // Here, you can start using Srv.Write to send the content out ...
     ...
    end;
end;

Best Regards,
Danijel Tkalcec

This is *exactly* the information I was searching for, and now it works.

Thanks a million.

Claudio