How to identify the origin of a DDP connection?

help
1

The problem:
I have a login server using Meteor accounts. That server also manages payments and a lot of other permissions and validations rules.
There is five applications who uses that server for authentication (trought DDP) and everything is ok.
But now, I have some specific app rules who can prevent a login and i wish to know the origin of a DDP connection on login.
So, for this I’ve been using the Accounts.validateLoginAttempt on the login-server to watch all login attempts and try to apply the proper rules of each of this apps. But looking in the connection info, I can’t figure the origin of the request:

{ 
  id: 'vvwBomDJDxHtNQi5s', //connection id
  close: [Function],
  onClose: [Function],
  clientAddress: '999.999.999.999', //
  httpHeaders: 
   { 
host: 'xxx.xxx.xxx.xxx:pppp',
     'user-agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.89 Safari/537.36',
     'accept-language': 'en-US,en;q=0.8,pt;q=0.6,it;q=0.4' } }

So, I don’t get any info of which app is calling login trought DDP. Just the client who is using it, and my login-server address: host: ‘xxx.xxx.xxx.xxx:pppp’

I get the same information looking on Meteor.server.stream_server.open_sockets

Any clues on how to solve this?

2

What do you mean by origin? HTTP Referer? If that’s the case then it depends on the browser to send this header and not all browsers do, plus user can easily disable sending it or even modify it to whatever value, so you shouldn’t really depend on it.

3

Yeah, could be HTTP Referer.
I probably misunderstood how a login trought ddp works. I’m thinking that my-app.whatever.com should manage and stablish the connection with my-loginserver.com; And not the user browser.

4

It’s hard to tell exactly what’s happening without knowing your exact set-up. Are you creating an Accounts instance in your client code using a connection parameter that points to your login server? If so, then it is the user’s browser which will connect to your login server, the request will not be router through the application server.

5

Yep, I’m doing exactly that way. Should I do it in another way?

6

Well, that’s the correct way to do it I think, but you will not get the app server address this way. If you want additional validation of the client, what you can do is first fire a method from your app server to the login server, which will give you some kind of token (and at this point you can check the origin on the login server), then pass that token to the client to be use alongside with the actual login. It sounds a bit complicated, but I don’t see a way around it to do what you want (you technically could route all login methods through your app server but that would be a bit complicated as well).

1 Like