WEBrick ignore bad host component - ruby

Is there a way to ignore a bad host component in Webrick?
I'm running a Sinatra/Rack service on localhost:3000. This service registers with a service-facade service running also on localhost; the service-facade will assign a URL app-key.1:1111 which will get routed to my application on localhost:3000. Therefore allowing a client to be able to talk to my service via the service-facade without having to know the host+port of my service. The problem is, the service-facade uses the wrong HOST in the header (it uses the app-key.1 host+port instead of localhost:3000) and I'm told that the people who manage the service-facade that it is not easy to change this header.
To give some more detail, the service-facade is written as a Java application. It takes the headers from the request and just reforwards it to the resource-server. As a result, you might think that as long as the client talking to the service-facade uses the correct HOST in the host header, then everything would work; however, this defeats the purpose of the service-facade because the client needed to know the resource-server's host beforehand.
I can fix it if I somehow hook something in before any of this host check happens. The funny thing is, that for some reason, Tomcat seems to not care about this host check so our Java applications that use this service don't seem to run into this issue.
Is there a way to bypass this check in WEBrick? Or maybe I can add the hostname somehow so that WEBrick will accept as a valid host as well?
The check specifically is: Exception `URI::InvalidComponentError' at /Users/bliu/.rvm/rubies/ruby-2.1.1/lib/ruby/2.1.0/uri/generic.rb:605 - bad component(expected host component): api_key.1
def check_host(v)
return v unless v
if #opaque
raise InvalidURIError,
"can not set host with registry or opaque"
elsif parser.regexp[:HOST] !~ v
raise InvalidComponentError,
"bad component(expected host component): #{v}"
end
return true
end

Related

OpenSIPS 2.4 call forbidden

I discovered OpenSIPS and all the possibilities a few days ago. I would just use it as a simple SIP proxy to get started. Proxy between my designated UAC and my UAS (asterisk, not natted). The goal is to use a proxy to prevent bot attacks on my UAS.
After installing OpenSIPS, I tried to configure my XLITE (natted) by simply adding the proxy URL in the configuration. It works, I register and I can see in my UAS peers my extensions with proxy IP. But when I make a call, I got a forbidden error. In debug mode, the log does not talk to me, I see a lot of information but nothing about this error.
I did not make any changes to the default configuration script. Is this behavior normal?
I also tried with VM on public IP as UAC (so not named), same thing.
Thank you for your help.
Olivier
Most likely, your SIP INVITE is hitting this block:
if (!is_myself("$rd")) {
send_reply("403", "Relay Forbidden");
exit;
}
What this means is that your OpenSIPS does not consider itself responsible for the domain (or IP) that your SIP UA has placed in the Request-URI and is trying to route towards. To fix this, just whitelist the Asterisk IP as a local (recognized) domain using the alias statement:
listen = udp:*:5060
alias = 1.1.1.1

websocket will not connect from remote server

I have a web page to control a thermostat on a raspberry pi, and I'm running into difficulties when trying to get websockets to work from a remote client. It seems to work fine when on LAN however. I'm obviously missing something (and likely something basic), but I can't seem to figure out what it is.
The pi's local ip is 192.168.1.134. The web page (served from apache server) has the URL http://192.168.1.134:8010/thermostat.html. The page starts up some javascript, which then tries to connect to the pi's main program using websockets via ws://192.168.1.134:9000. (the server on the pi is running libwebsockets). The websocket comes up, and it seems to work fine. I then tried to connect via a remote client (a cell phone, where wifi was turned off) from http:\\23.239.99.99:8010\thermostat.html. The html/js files load fine, but the web socket attempts to connect to uri ws:\\23.239.99.99:9000, and this fials.
As far as I can tell, the NAT seems to be configured properly:
name ext ext protocol int int ip addr interface
port port port port
start end start end
Thermostat3 8010 8010 TCP 8010 8010 192.168.1.134 eth3.1
Thermostat5 8000 8000 TCP/UDP 80 80 192.168.1.134 eth3.1
Thermostat_ws 9000 9000 TCP/UDP 9000 9000 192.168.1.134 eth3.1
I checked, and the router does not have any firewalls set up, neither does my modem. I didn't install a firewall on the pi (I checked, and there's no odd iptables rule). Does anyone know what I'm missing?
--- EDIT ---
I'm still stuck on this. I called my ISP and they assure me there are no firewalls on their servers. Is there any way to tell if port 9000 is being blocked, and by who?
Bind your apache server to 0.0.0.0 address to make it accessible from remote machines
Try this tool to determine if the port is inaccessible (use the custom port): http://www.whatsmyip.org/port-scanner/
Everything else looks fine. As a sanity check I would try putting the ws port to 8010 to see if that works. I would also recommend using a tool like Advanced Web Client to isolate networking issues.
This is interesting. I once had a similar problem. I set up a WebSocket (I was using a nodejs ws) and once I tried to access it from remote client I was not able to reach it with ws://yourip:port but instead I had to use http://yourip:port. I don't know if you have the same problem, mine was due to a proxy I was using.
I still have an advice for you how you might be able to solve your problem. I don't know how concerned you are about security but as far as I understood your idea you basically connect to your raspberry pi through a WebSocket and tell it to change the temperature.
Back when did a similar project I found it rather hard to secure my WebSocket connection. I was basically sending a password plus command through the WebSocket to my server which then checks wether the password is correct. Otherwise everyone on the internet could heat your house. Not cool...
But therefore, I had to tunnel the connection through https to prevent a middleware attack.
I quickly threw the towel and decided to go with a completely different solution. Basically I set up a nodejs express server (can easily be configured with a self signed certificate to use https or used behind a nginx/apache https server) and authenticated with username and password. When someone made a POST request to /api/thermostats?id=0 with a temperature request, the server checks if the user is authenticated and then executes a terminal command from within node.
Maybe this idea also fits your demands.

'net use' over SSL fails unless port 443 is specified

We are attempting to connect to a WebDAV server using net use over SSL. On some servers we're seeing an issue in which this connection only succeeds if we specify port 443 in the URL.
Does Map
net use * "https://example.com:443/folder"
net use * "\\example.com#SSL#443\folder"
and, bizarrely, so does this:
net use * "\\example.com#SSLasdf\folder"
Does Not Map
net use * "https://example.com/folder"
net use * "\\example.com#SSL\folder"
In the non-working cases we consistently receive the following error:
System error 67 has occured.
The network name cannot be found.
We have noticed some things that might be useful information:
We have a test server that's configured the same way as the prod server and it works as expected.
In the non-working cases, no incoming requests are ever seen at the prod server from the failing host.
All clients are based on the same image.
The problem does not manifest uniformly on all clients -- some work, some don't.
There is an existing, valid entry for example.com in the client DNS cache.
Flushing the client DNS cache of the affected servers does not resolve the problem.
Once the problem appears, it seems to stick. That is, if I execute one of the working mappings, delete it, and then immediately execute one of the non-working mappings, the problem persists.
We are utterly stumped. Any theories?
You are seeing different behaviors because you are connecting using different names. Once a name has been attempted and failed, the WebClient (this is the service that enables WebDAV) will cache the response for a period. To clear the cache, locate the WebClient service in the Services console and restart it. Or from an administrative command prompt execute the following command:
net.exe stop webclient && net.exe start webclient
We ultimately determined that we were mis-interpreting the System Error 67 that net use was returning. We discovered two interesting things:
In the event that the WebDAV returns a 404 or a 50x on the initial, root folder PROPFIND, net use will (rightly) interpret this as the root folder being unavailable. The fact that it says the network name could not be found let us to believe that the problem was with the name resolution, but it was really just saying, 'hey, I couldn't find anything at this path.'
If 'net use' fails due to a 404/50x, it appears that for a brief period of time it will automatically fail any additional mappings for that same host without issuing a request. For example, if net use http://me.com/foo returns a 404, then net use http://me.com/bar will instantly fail if made in rapid succession to that first call, and no request record will be seen in the WebDAV server logs.
My best guess is that appending the #443 port didn't make any real difference. What it perhaps did do was to trick net use into thinking it was talking to a different host, at least for the purposes of its 'auto-fail' feature. But that's just a guess.

Node.js: Running example of Chat?

Trying to setup an example for node.js chat on Windows x64.
Command line:
D:\Websites\dev\chat>node server.js
Server at http://127.0.0.1:8001/
Now when server part runs, trying http://dev/chat/index.html
After submitting Name, it gives me "error connecting to server".
Same error message on http://chat.nodejs.org/
Does the thing actually work? =)
Do I need to set up an Apache's mod_proxy to handle /join to port 8001?
Some of the issues are with using http://dev/chat/index.html and also, I suspect, with:
Do I need to set up an Apache's mod_proxy to handle /join to port 8001?
Node's http module is more for creating the server than it is for integrating with other servers like Apache. (It's possible, e.g. iisnode, but not the default.)
While node server.js is running, you should be able to access index.html via either:
http://localhost:8001/
http://127.0.0.1:8001/
Then, /join, /recv, /send, etc. should be able to route through the same origin.
Otherwise, using http://dev/ has 2 problems:
Requests will route based on the current address. For example, /join will request http://dev/join rather than http://127.0.0.1:8001/join, likely resulting in a 404 response. And, even if you modified the client script to specify the origin...
Same-origin policy. Pages requested from http://dev/ cannot make Ajax requests to http://127.0.0.1:8001 without exceptions, which this demo does not have established.

Websocket session.Path

I've been playing around with the SuperWebSocket code, pretty cool stuff, but I'm not sure why we really need to set the path at the end of the url as in:
ws = new WebSocket('ws://<%= Request.Url.Host %>:<%= WebSocketPort %>/sample');
I left the 'sample' at the end out from the url and it still works. Why do we need it at all? I didn't see anywhere in the code where it was used except for some logging.
Can someone shed some light on the 'session.Path' thing?
Thanks much,
The path part of the URL is so that you could have different WebSocket server applications running on the same port. In other words, WebSocket connections default to 80 and 443 in order to use existing infrastructure and network configuration. However, you still might want to serve multiple WebSocket applications so that is what the path is for. If you only have a single application running on that port, then you can ignore the path.

Resources