delight-im / Android-DDP

[UNMAINTAINED] Meteor's Distributed Data Protocol (DDP) for clients on Android
Apache License 2.0
274 stars 54 forks source link

WebSocket URL change or authentication #111

Closed EbuOgden closed 8 years ago

EbuOgden commented 8 years ago

Hi everyone,

I am trying write an native android app which use meteor for backend.

I am wondering about connect server websocket to another url. Let me explain about that ;

I can connect localserver with this line =

new Meteor(this, "ws://192.168.1.20:3000/websocket", new InMemoryDatabase());

but think about in deployment. For example; let assume my meteor application ip is '111.23.32.1'

and i can connect in android application with like this :

new Meteor(this, "ws://111.23.32.1/websocket", new InMemoryDatabase());

BUT anyone can connect my server and take my datas over DDP with this line.

Can i add authentication for "/websocket" URL or can i change "/websocket" URL?

I'm not talking about Meteor User Login method, i have an application which don't need users login to see datas, I removed autopublish but i have to show all datas to all users. If i add autopublish, anyone whom know my server ip, will can take my datas.

How can i prevent this?

May i use subscription method with uniq id parameter, which given by my self?

Thanks.

ocram commented 8 years ago

BUT anyone can connect my server and take my datas over DDP with this line.

Yes, and you cannot really do anything about it. That's important, and it's not specific to Meteor!

Always imagine that some other person might built an alternative client that connects to your server. So all (!) security mechanisms must be on the server, not in the client. Again, this is not a problem that Meteor introduces, but it's a problem that you have with any language, framework or approach.

Think about it: What do you want to do in order to prevent this? Adding a secret key into your client is almost the only thing you can do. You can do this, and maybe you really should in your case. It prevents many "attackers" from accessing your API in a way you don't want. But what prevents a real attacker from inspecting your client, extracting the (formerly) secret key and then using it to access your API with their own client?

BUT anyone can connect my server and take my datas over DDP with this line.

You should not let anybody extract tons of data, of course. Consider rate limiting, where you prevent any client from accessing too many resources.

May i use subscription method with uniq id parameter, which given by my self?

Yes, something using unique IDs is probably a good idea. Another common solution is secret keys hard-coded into your client, with the downsides described above.

Does that help?