I want to distinct servers from a REST API.
I have a REST api, a WebSocket and X local servers (The amount change every minutes, from 1 to 20).
The REST api and the websocket are both in php, while local servers are in Java.
The servers are all connected to the websocket. So they can communicate between them.
The servers and the websocket can send requests to the REST api.
The problem is, I want to allow anybody to send requests to the REST server.
So, I have to authenticate the websocket and the servers through REST server to allow some actions (for example create users) to the WebSocket and others actions (for example login) to servers.
All these servers are on the same machine (==> localhost).
Do you have any ideas how can I authenticate servers and WebSocket ? I think that OAuth2 is good only for other users (Not WebSocket and not Java Servers).
I don't know if private and public keys are good in this situation, if yes, how can I use it ? Or maybe I have to create different passwords for WebSocket and all Java servers ?
Thanks,
0ddlyoko
OAuth2 can still be a good idea. You will not be able to use the Bearer HTTP header, because there are no real HTTP headers in Websockets, but you can still send that token over to authenticate.
Having one standard way to handle authentication is a good thing.
Related
I have 3 server that same server application is running on each of them. each installation of server app has its own configurations, data and settings.
other client users or client applications can connect to this servers and communicate with them.
this servers are in different places.
this application are created by PHP and servers are ubuntu servers, each server has its own static IP.
but now i need to share some data between this server applications. for example server A needs to access to information of server B's customers. or main admin of system want to see some information of server C. other scenario may be back up/sync. each server with 4th server with special application.
what is the best and more secure way to share some data between server applications? for example application A on server A needs some data get from application B on server B, or send some data to it.
There are several ways to do this, and it depends on if your goal is to send data synchronously or asynchronously.
If you want to send data synchronously (that is, send data, and wait for a response before proceeding to whatever the next step), use HTTPS.
If you want to send data asynchronously (that is, send data, then go off and do something else while the response can come back at any time), use XMPPS.
Both run over SSL, so that will handle the security side of things. Both HTTP and XMPP services are plentiful, so building the scripts to use these services for communication would be relatively straight-forward.
I've been reading this book about PHP and MySQL and at the end of each chapter it asks you some questions for you to research about and one of them I don't really get:
What is a Proxy script? When might a proxy script be necessary?
I hope you could help me answering this question because I don't really know what it is (I do know what a proxy server is though)
From WikiPedia's article on Proxy Servers
In computer networks, a proxy server is a server (a computer system or
an application) that acts as an intermediary for requests from clients
seeking resources from other servers. A client connects to the proxy
server, requesting some service, such as a file, connection, web page,
or other resource available from a different server and the proxy
server evaluates the request as a way to simplify and control its
complexity.
That explains it pretty much. So basically, a PHP proxy script can be used to access the blocked content i.e. websites in a network i.e. a college's WiFi network.
For an example, suppose facebook.com is blocked by your college's WiFi and you want to access it then a PHP proxy script might come in handy. Which will take requests from you and send it to the facebook on your behalf and sends the received data back to you. So you're not directly communicating with the facebook's server but that proxy script is doing that job for you.
Here's a simple PHP proxy script I found from a quick search that you might find helpful : Simple-php-proxy-script
I am thinking about a scenario where I want to send a data packet from my php service (based on certain behaviour) to a client (can be Android or Windows) connected to it.
A device which is connected to the internet is going to have an ip address.
So is it possible to send a packet (using socket or else) to this ip directly (without polling from client end) and can this data be read from the client.
Scenario is like this :
Client A --------------Registers Own IP Address-----------------> Server
Client B --------------Registers Own IP Address-----------------> Server
Events :
Some changes occur in the database (say)
Server detects the affected client (via some algo),say Client A
Sends a packet to Client A
Client A <--------------Send Data Packet----------------- Server
Is this at-all possible ?
If yes, how effective can this be ?
Please note that, Push notifications is not applicable in my situation.
I am looking for a live (realtime) data transmission system between client and server (both ways).
Any suggestion, help will be useful. Thanx
Absolutely possible to have persistent sockets open.
but I would say this would fail in a hosted environment. GoDaddy etc shuts that down. Been there done that.
I would highly recommend choosing a programming language like java (Whatever you are comfortable with). It is only going to be 200 lines of code.
I have following scenario:
The Android clients communicate with a PHP server via HTTP Post. The PHP server is communicating with mySQL database and sends the output as JSON to the Android client.
Now I am concerned that people sniffing the traffic, find out the URL and will post a lot of grap in my database.
I have no concern of sniffing the payload. So it does not necessarily be encrypted.
I was thinking of TLS/SSL which comes in mind because of the HTTP connection. But I am not sure what is the prefered way to go in this scenario.
What you want to do is employ mutually-authenticated SSL, so that your server will only accept incoming connections from your app and your app will only communicate with your server.
Here's the high-level approach. Create a self-signed server SSL certificate and deploy on your web server. You can use the keytool included with the Android SDK for this purpose. Then create a self-signed client and deploy that within your application in a custom keystore included in your application as a resource (keytool will generate this as well). Configure the server to require client-side SSL authentication and to only accept the client certificate you generated. Configure the client to use that client-side certificate to identify itself and only accept the one server-side certificate you installed on your server for that part of it.
If someone/something other than your app attempts to connect to your server, the SSL connection will not be created, as the server will reject incoming SSL connections that do not present the client certificate that you have included in your app.
A step-by-step for this is a much longer answer than is warranted here. I would suggest doing this in stages as there are resources on the web about how to deal with self-signed SSL certificate in Android, both server and client side. There is also a complete walk-through in my book, Application Security for the Android Platform, published by O'Reilly.
SSL won't help you, as the traffic can be sniffed before the data hits the wire, and people will STILL be able to figure out your API calls and fill the DB with crap.
You can "secure" the service with access tokens and username/password requirements. But again, they won't prevent a malicious user from flooding your system with bad data. However, it would let you track down WHICH user was doing so, as they'd have to be using a unique access token of some sort to get at your system.
I have recently written a socket server in PHP that will be handling communication between an Android phone application and my PHP webserver. Due to the fact that Android doesn't natively support push style notifications we are going to be using our webserver as the middleware layer to handle our 'pushes'.
The socket server is stable, runs well, and seems to scale nicely. While I would eventually like to re-write this in C I don't have the skill necessary to do that right now so I am going to be staying in PHP for at least a short while. As of this moment our Android emulator is able to communicate through the server, get pushes, etc. so that part is all covered.
My concern is that, right now, anyone can open a socket to my server and will be given a client connection. While we won't be passing sensitive data back and forth I don't want to allow just anyone to connect over and receive broadcast information, eat up my resources, and clog my server in general.
The question is, how do I secure a server like this? Let's assume that I am running on port 25,000--can I set up some sort of SSL layer on that port and expect devices like the Android to be able to communicate over that port without any special protocols or jumping through hoops?
I have considered asking the connecting clients to authenticate their user against our user database before being given a client connection, but that would require the passing of credentials in plain text over the network which I am NOT about to do.
Any suggestions on this would be very helpful--I am rather new to straight TCP communication from PHP and feel like I might just be missing something simple that allows for authentication on this level.
Additional information: If I am able to get a valid username and password securely I would be using MySQL to validate the user and then accept/reject their connection based on the results of the query.
Thanks in advance..
First, I hope you've implemented your PHP socket server in a fashion that allows more than one client to be connected at the same time. This is not as trivial as it should be given the absence of threads in PHP, but it's certainly.
Now, if you already have a socket server implemented, adding TLS support is easy. Just run stunnel and have your PHP socket server only accept requests on the local interface.
I don't think SSL is really going to solve your problem. At best with SSL you can provide each client with a client certificate and do client certificate validation on the server. But you'll need to manage tons of certificates then. Or give everyone the same client certificate (not a good idea).
You'll have to authenticate the client using his credentials. You are right that you don't want to send the credentials in plain text over the network, but there are simple alternatives. Take a look at e.g. HTTP Digest Authentication (http://en.wikipedia.org/wiki/Digest_access_authentication) or xAuth (http://dev.twitter.com/pages/xauth). You don't have to implement these techniques over HTTP; you can just as well send a challenge (a realm) over a simple tcp socket after you have accepted the connection. The client should then send a valid response within a short timeframe or the server aborts the connection.
By the way, did you consider HTTP streaming? See http://ajaxpatterns.org/HTTP_Streaming
It would probably make your life a lot easier as you can rely upon some other service (e.g. Apache) doing the hard work for you, and you can focus on the business value of your application.
you might want to consider:
Cloud to Device Messaging : http://code.google.com/android/c2dm/index.html
The only drawback is that it is only supported by android >=2.2
Not sure why you guys didn't use some off the shelf messaging library/server for java, then create an android service that connects to the message broker and handles all initial authentication.
The service would simply sit there and wait for any incoming messages.
(I'm pretty sure that listening for network data doesn't power up the radio, only when the data is actually there that the radio powers up. I suspect this is how C2DM works.)
This is better then polling because you're only waiting for data. You're not constantly sending packets requesting data. But you knew that already.
I did this, (I used the rabbitmq-java library and the rabbitmq message queue server) and had push style notification for my app in no-time. Even with Android 1.5 devices.
About security:
You could also implement your own security but without having to send plain-text passwords. Simply encrypt the passwords using something like MD5 before passing it through the network.
Then compare the encrypted password with the encrypted password you have on file.
This way, only encrypted passwords will go through the network.