We Keep Coding

Connecting socket.io client to different hosting

So a website of mine is hosted on godaddy, now I want to connect it with a server that is running socket.io, and I have some balance on digitalocean. However, I am not sure how I would do this, I think it should be like this for client side?
var socket = io.connect('http://Digital.ocean.ip.here:port');
and then server side like this
http.listen(port, function(){
console.log('listening on *:port');
});
the only thing is that if this is how I am supposed to do it (and it even is possible if it's not the localhost), than users will be able to see the ip of my droplet when they take a look in the source code, and perhaps DDOS it or maybe worse I don't know?
When I see other sites using socket.io for a chat for instance, I never see their IP. Does that mean they host their entire website on a service provider where they are able to use socket.io/node.js?
Any answer will be highly appreciated!
--Edit--
My client wouldn't accept http and therefore I decided to buy a domain and ssl so it would use https.

There's no way to every hide the IP address of a server that a browser connects to. It makes no difference whether the connection to the server is http or socket.io or any other TCP based connection. Anyone can see the IP address. So, that simply isn't something you can protect or should worry about.
In most cases, code will use a DNS host name (not an IP address), but the DNS service itself provides a way to lookup the IP address for a host name so the IP address can be fetched that way. Or, one can just load a debugger or local network snooper and easily see what IP address is being connected to. A host's IP address is simply not a secret.
If you are worried about DDOS, then you will have to implement server-side protection from those types of attacks. You can't do anything in the client to protect from those kinds of attacks.

How to discover a DHCP ip of an arduino in local network with javascript

I'm using an arduino UNO and an Ethernet Shield to create a web server to response HTTP requests.
The requests are sent by ajax XMLHttpRequest.
It's working fine with static ip address.
But a want the arduindo to get a DHCP ip, so I can use it in any local network (with DHCP).
I want to discover the ip of the arduino connected on the local network.
So I can use it as url to send HTTP requests.
Is it possible to do that in javascript?

OK, thanks for answering my questions above. That helped layout the network structure and the problem you're trying to solve.
Summary of the problem
Two computers: 1 web server whose address is dynamic (DHCP) and 1 web client running AJAX and HTML. How can browser find DHCP server?
Options
This is a classic problem solved many different ways throughout the history of computer networks. I've suggested some options below.
Scan for the server via TCP.
Scan for the server via UDP (requires special browser library).
Run a DNS server.
Have Arduino signal its IP.
Modify your router.
Don't run DHCP - use a static IP.
tl;dr - Use Option 6 if you don't control your router, Option 5 if you do.
Option: Scan for the server
I'm assuming you know your browser machine's IP address (for example, 192.168.1.17). In this case, run through all of the address from 192.168.1.0 through 192.168.1.254 (not .255 and skip you browser machine's IP) testing for a connection to port 80. This will find every web server on your subnet, so be aware you will need a way to recognize your arduino responded to the web request in case some other web server is also listening on the network. It will also take some time to set up, test and wait for timeouts on most (252) of the addresses which don't have web servers. You will eventually find it.
I'm not a fan of this one, but it gets the job done. Warning: if you don't "own" the network, someone may be angry with you for scanning their machines. A company, school or other institution may have policies about not scanning networks.
Option: UDP from the browser
This one is great, but requires a browser plug-in and some fancy coding. UDP allows one to broadcast a message to your subnet (try ping 255.255.255.255 at a command line and watch the machines echo back their IPs). If the arduino is set to listen for UDP packets on a particular port, it can echo back to the sender of the UDP packet and let that user know it's present. This is how DNS, DHCP, ping and Apple's Bonjour work. Many IP based systems advertise services by responding to UDP requests. Clients need not know the address of the servers on the subnet, they discover them through broadcast messages on well-known UDP ports.
Unfortunately, this requires a browser modification because Javascript does not support UDP for security reasons. I understand this and agree with the security restriction. However, it has cut out a really nice feature of dynamic service discovery. If you're on Apple on the browser, you might be able to find a Bonjour emulator you can run on the Arduino and it might work ("arduino.local" might attach). This might be possible with Windows service discovery, too, if you're using a Windows client for your browser. I don't know what's available in Linux for service discovery.
I don't like any of these modifications for you. Browser, Arduino (Apple, Windows or Linux), just because it adds more moving parts and you're counting on the browser to "know" how to find the service.
Option: Run a DNS server
This isn't as bad as it sounds, but I'm not sure the Arduino could handle it. Find a very small DNS server written for the Arduino and have it respond to DNS requests. On the browser, look for a well-known machine name (e.g. "my-arduino.lan"). This essentially finesses the UDP problem above by making the Arduino the UDP server (handles DNS requests) and the browser already has name resolution s/w (like every machine on the planet).
I didn't search for Arduino DNS code, it might be too large for the Arduino and writing it may be a real PITA (pain in the butt).
Option: Arduino signals IP
In this model, you can attach a LCD to the arduino and have it present its IP address on the display. Alternatively, the arduino can send a message (via TCP) to a well known server on the network (internet or otherwise) reporting its IP address there. Your browser can query that server, pick up the IP address and then contact the Arduino directly. This introduces a 3rd machine and acts like your own hacked form of DDNS (look it up, if you're not familiar with it).
Option: Modify the router
If you own the router, you can modify the router to assign a specific IP address to the Arduino, even with DHCP. This is your best bet. Here, you control the network, can allow the Arduino to come up in DHCP while still fixing its IP address. You'll have to go through your router API (web or CLI) and figure out how to do it, it's a bit hard directing you as there are thousands of types of commercial and SOHO routers.
If you don't control the router...
Option: Use Static IP
This option is really your best. Give up on DHCP and just set the static IP of the arduino. Just make sure the IP address you pick doesn't conflict with any other servers on the subnet. That shouldn't be difficult.
I hope this helps.

The 2 best options I think:
1) When arduino starts, gets an IP address from DHCP, arduino should make a connection to a well know service provided by you. Also, each device should have an ID, defined by you during manufacturing, like mac address or part of mac address.
So, you can print on the box something like: 5c4e6f.my-well-know-host.com
Than, as I was suggesting, each time arduino starts, it tries to connect to that service passing parameters like:
POST www.my-well-know-host.com
ID: 5c4e6f
IP: 192.168.1.55
than, at that service, you update a DNS table to reflect this relation:
5c4e6f.my-well-know-host.com -> resolves to 192.168.1.55
obviously, from anywhere in the world the host 5c4e6f.my-well-know-host.com will resolve to 192.168.1.55, but you will only access it from you local network.
Tip: this is some kind of DDNS, but with network discovery purposes.
Tip2: there is an linux dns service called MyDNS, where the hosts are simply records inside a MySQL table, easy to maintain.
2) Network discovery
I don't know if arduino is capable to do it, but, the idea is to make arduino listen on a specific UDP port, like 4444, on any address.
So, you can build a windows app, and Android APP (I already made one android discovery for another purpose, not arduino), or, the best solution that I still researching on, is to make a custom page with some javascript code, that "looks" for devices listening on that specific port.
Works like that:
Device gets IP from DHCP
device starts a thread listening for broadcast packets on port 4444
a discovery app listen on another port, like 4445.
the discovery app announces itself using a broadcast packet to 4444 port (255.255.255.255:4444)
each device listening, reports back with its identification and IP to app port 4445.

This is a code to find the server ip:
<script type="text/javascript">
var ip = "<?php echo $_SERVER['SERVER_ADDR']; ?>";
alert(ip);
</script>
If you are using Johnny Five framework, then you can find APIs in that framework

Amazon cloudfront IP resolution by client

I have a webapp that uses a lot of images which are cached through CloudFront. Some users complain that the load time is excruciatingly slow, So I want to build a diagnostic page on the site that will do a speed test by loading a few images and reporting the time. I also want to report the users IP address (which I can easily get from php when they load the page), but I also want to show the IP address that they are getting for the cloudfront server.
I know that if I run:
dig subdomain.cloudfront.net
I get several IP addresses. If an app (browser, QT app, mobile app) is running simultaneous connections to subdomain.cloudfront.net, does it always use the first IP first and use the others only if it fails?
And is there any way from within the browser that I can get these IP addresses as they are from the client users system? It's my understanding that they will get a different list of IPs based on their IP address.
If this is not possible from within the browser, is there any type of request that I could send to the cloudfront server that would include it's IP address in the response?

does it always use the first IP first
Most modern DNS resolvers and authoritative servers will randomise the order of the IP addresses -- more precisely, the set of A records for a given domain name.
So, "first IP" really isn't deterministic at all.
and use the others only if it fails?
Obviously this is very browser-dependent. Most modern browsers do handle it by retrying the other IPs. I wouldn't count on it though.
is there any way from within the browser that I can get these IP addresses as they are from the client users system?
From Chrome devtools network panel, you can see the address that the browser connected to in the "Remote Address" field of a request. However, I'm not aware of any way to access that from Javascript on a page.
It's my understanding that they will get a different list of IPs based on their IP address.
Yes.
is there any type of request that I could send to the cloudfront server that would include it's IP address in the response?
Not that I know of. However, you might be able to reverse engineer the Via or X-Amz-Cf-Id response header? At a cursory glance, both are unintelligible to me after hex or base64 decoding.
That said, there is a trick that you might be able to use, i.e. that you could setup a URL prefix in your distribution that forwards the requests to your server running PHP. You then point your users to a URL that would result in a request that gets forwarded to your PHP script. In your PHP script, examine the X-Forwarded-For header, which should include a Cloudfront IP.

Do I need to register a domain with an OAuth2 provider, like google, or can use my own IP address/Localhost to send requests?

I can't push my code to my domain and have been testing up until this point on my local web server, 127.0.0.1. But can I avoid registering a domain with the OAuth2 providers, and send requests from my IP address?
So far, I've done all research, but I've seen no indication that is is not possible. I've also seen no explicit information that it is.
Thanks for your help!

You can register any domain, including localhost for local testing.
The Oauth server will not contact that domain by itself. It will only redirect users back to that domain as part of the authentication process, which works just fine when you test it locally with localhost.

Secure JavaScript Running on 3rd Party Sites

We have a "widget" that runs on 3rd party websites, that is, anyone who signs up with our service and embeds the JavaScript.
At the moment we use JSONP for all communication. We can securely sign people in and create accounts via the use of an iFrame and some magic with detecting load events on it. (Essentially, we wait until the iFrames source is pointing back to the clients domain before reading a success value out of the title of it).
Because we're running on JSONP, we can use the browsers HTTP cookies to detect if the user is logged in.
However, we're in the process of transitioning our system to run realtime and over web sockets. We will still have the same method for authentication but we won't necessarily be making other calls using JSONP. Instead those calls will occur over websockets (using the library Faye)
How can I secure this? The potential security holes is if someone copies the JavaScript off an existing site, alters it, then gets people to visit their site instead. I think this defeats my original idea of sending back a secure token on login as the malicious JavaScript would be able to read it then use it perform authenticated actions.
Am I better off keeping my secure actions running over regular JSONP and my updates over WebSockets?

Websocket connections receive cookies only during the opening handshake. The only site that can access your websocket connection is the one that opened it, so if you're opening your connection after authentication then I presume your security will be comparable to your current JSONP implementation.
That is not to say that your JSONP implementation is secure. I don't know that it isn't, but are you checking the referrers for your JSONP requests to ensure they're really coming from the same 3rd-party site that logged in? If not, you already have a security issue from other sites embedding your javascript.
In any case, the 3rd-party having an XSS vulnerability would also be a very big problem, but presumably you know that already.

Whether you are sent cookies during opening WebSocket handshake by browser (and if so, what cookies) is not specified by the WS spec. It's left up to browser vendors.
A WS connection can be opened to any site, not only the site originally serving the JS doing the connection. However, browsers MUST set the "Origin" HTTP header in the WS opening handshake to the one originally serving the JS. The server is then free to accept or deny the connection.
You could i.e. generate a random string in JS, store that client side, and let that plus the client IP take part in computing an auth token for WS ..