I am trying to accomplish a simple task:
Every request with a URI of:
http://localhost:8081/api/customers
Will also be available through:
http://somedomain.com:8081/api/customer
I've defined my hosts file:
127.0.0.1 somedomain.com
So if the URI is:
somedomain.com
It is being redirected to localhost - the default IIS8 page - which is the wwwroot folder on windows. Great!
However the followings don't work:
somedomain.com:8081
nor
127.0.0.1:8081
Anyway to make it work?
P.S
ASP.NET Web API doesn't work very well with localhost address (for instance you cannot add cookies from the server for localhost address).
Related
I keep getting an Invalid HOST Header error which I am trying to find the cause of. It reads as such:
Report at /GponForm/diag_Form
Invalid HTTP_HOST header: '192.168.0.1:443'. You may need to add '192.168.0.1' to ALLOWED_HOSTS
I do not know what /GponForm/diag_Form is but from the looks of it, it may be a vulnerability attacked by malware.
I also am wondering why the IP is from a router 192.168.0.1 as well as why it is coming through SSL :443
Should I consider putting a HoneyPot and blocking this IP address? Before I do, why does the IP look like a local router?
The full Request URL in the report looks like this:
Request URL: https://192.168.0.1:443/GponForm/diag_Form?style/
I am getting this error at least ~10x/day now so I would like to stop it.
Yes, this surely represents a vulnerability - someone tried to access this url on router (which usually have ip 192.168.0.1).
It looks so because request from attacker contains HOST header with this value.
Maybe django is run locally with DEBUG=True.
You may consider running it more production wised with web-server (i.e. nginx) in front filtering unwanted requests with nginx config and further adding fail2ban to parse nginx error logs and ban ip.
Or make site available only from specific ips / ads simple authorization, i.e. Basic Auth on web-server level.
Previous irrelevant answer
ALLOWED_HOSTS option specifies domains django project can serve.
In running locally - python manage.py runserver or with DEBUG=True - it defaults to localhost, 127.0.0.1 and similar.
If you are accessing django via different url - it will complain in such a manner.
To allow access from another domains - add them to ALLOWED_HOSTS: ALLOWED_HOSTS = ['localhost', '127.0.0.1', '[::1]', '192.168.0.1'].
I have used ShimmerCat with sc-tool to connect to my development sites as described here, and everything has worked always like a charm with it, but I also wanted to follow the "old way" configuring my /etc/hosts. In this case I had a small problem, the server ran ok, and I could access to my development site (let's say that I used https://www.example.com:4043/), but I'm also using a reverse proxy as described on this article, and on the config file reference. It redirects to a Django app I'm using. Let's say it is my devlove.yaml config file:
---
shimmercat-devlove:
domains:
www.example.com:
root-dir: site
consultant: 8080
cache-key: xxxxxxx
api.example.com:
port: 8080
The problem is that when I try to access to a URL that requests the API, a 404 response is sent from the API. Let me try to explain it through an example. I try to access to https://www.example.com:4043/country/, and on this page I do a request to the API: /api/<country>/towns/, then the API endpoint is returning a 404 response so it is not finding this URL, which does not happen when using Google Chrome with sc-tool. I had set both domains www.example.com, and api.example.com on my /etc/hosts. I have been trying to solve it, but without any luck, is there something I'm missing? Any help will be welcome. Thanks in advance.
With a bit more of data, we may be able to find the issue. In the meantime, here is a list of troubleshooting tips:
Possible issue: DNS is cached in browser, /etc/hosts is not being used (yet)
This can happen if somehow your browser has not done a DNS lookup since before you changed your /etc/hosts file. Then the connection is going to a domain in the Internet that may not have the API endpoint that you are calling.
Troubleshooting: Check ShimmerCat's log for the requests. If this is the issue, closing and opening the browser may solve the issue.
Possible issue: the host header is incorrect
ShimmerCat uses the Host header in HTTP/1.1 requests and the :authority header in HTTP/2 requests to distinguish the domains. It always discards any port number present in them. If these headers are not set or are set to a domain other than the ones ShimmerCat is configured to listen, the server will consider the situation so despicable that it will just close the connection.
Troubleshooting: This is not a 404 error, but a connection close (if trying to connect un-proxied, directly to the SSL port where ShimmerCat is listening), or a Socks Connection Failed (if trying to connect through ShimmerCat's built-in SOCKS5 proxy). In the former case, the server will print the message "Rejected request to Just https://some-domain-or-ip/some/path" in his log, using the actual value for the domain, or "Rejected request to Nothing", if no header was present. The second case is more complicated, because the SOCKS5 proxy is before the HTTP routing algorithm.
In any case, the browser will put a red line in the network panel of the developer tools. If you are accessing the server using curl, like this:
curl -k -H host:api.incorrect-domain.com https://127.0.0.1:4043/contents/blog/data-density/
or like
curl -k -H host:api.incorrect-domain.com
(notice the --http2 parameter in the second form), you will get a response:
curl: (56) Unexpected EOF
Extra-tip: There is a field for the network address in the browser's developer tools. Check it, it may tell you something!
Possible issue: something gets messed up when passing the request to the api back-end.
API backends are also sensitive to the host header, and to additional things like authentication cookies and request parameters.
Troubleshooting: A way to diagnose things is invoking ShimmerCat using the --show-proxied-headers command-line option. It makes ShimmerCat to report the proxied headers to the log:
Issuing request with headers :authority: api.example.com
:method: GET
:path: /my/api/endpoint/path/
:scheme: https
accept: */*
user-agent: curl/7.47.0
Possible issue: there are two instances or more of ShimmerCat running
...and they are using different configurations. ShimmerCat uses port sharing among several processes to increase availability. A downside of this is that is perfectly possible to mistakenly start ShimmerCat, forget about stopping it, and start it again after changing some configuration bit. The two instances will be running at the same time, and any of them will pick connections made to the listening port.
Troubleshooting: Shutdown all instances of ShimmerCat, then double-check there are none running by using the corresponding form of the ps command, and start the server with the configuration you want.
I have a WSO2 Identity Server behind a reverse apache proxy. The proxy listens on port 443 and the IS on port 9443.
I can see the dashboard (https://myhost/dashboard/) but as soon as I click 'Login' I am redirected to the wrong port (https://myhost:9443/samlsso )
I followed all the relevant instructions about putting the IS behind a proxy but it does not work.
In my apache config I have:
ProxyPass / https://localhost:9443/
ProxyPassReverse / https://localhost:9443/
SSLProxyEngine on
In my repository/conf/carbon.xml I have set <HostName> and <MgtHostName> to the name of the proxy.
In repository/conf/tomcat/catalina-server.xml I've added proxyPort and proxyName to the Connector.
Is there something else which needs to be configured?
Update:
I grepped for 9443/samlsso and changed those occurrences in the configuration files but it did not solve my problem. I am still redirected to port 9443.
Then I grepped for 9443 and found ~80 occurrences in the configuration files. I find it hard to believe the proper way of configuring a simple port change is to change all those 80 occurrences.
Since people are still interested in this I dug up my notes on this and share the solution we had. It kind-of worked but I'm not sure if it is the proper solution and its not perfect but should get you started.
(We gave up on WSO2 stuff because of these and other problems)
So what we did for version 5.0.0 was:
change {{ site }} into localhost:9443 in :
identity.xml
security/authenticators.xml
security/sso-idp-config.xml
(and probably also in account-recovery-gadget.xml and dashboard-index.jag)
add the property proxyPort="443" to the connector for port 9443 in tomcat/catalina-server.xml
change the function getServerUrl() in deployment/server/jagerryapps/dashboard/util/utility.jag into return "https://localhost:9443/services";
change var postUrl = ... into var postUrl = 'https://{{ site }}/samlsso'; in samlsso.jag
So I want to do this:
myapp.com -> localhost (ColdFusion local web server)
I can currently only do this:
localhost/myapp_folder/
Any ideas on how to achieve this using built in web server?
One solution is to add
127.0.0.1 myapp.com
to your windows/etc/hosts file
(You'll need to do this as an administrator, so right click notepad and 'Use as administrator', browse to the file and edit that way).
This will make all requests on your local machine for myapp.com point to 127.0.0.1 (i.e localhost) - don't forget to remove it when you're done testing, as it will obviously stop you looking at the real site when you go live with it.
This will allow you to do myapp.com/myapp_folder/, but if you want to map /myapp_folder/ to the root of the myapp.com domain using the technique above, you'll have to use something more sophisticated like apache or IIS.
I want to let the same user session span across:
site.com
sub1.site.com
sub2.site.com
I got this to work in production by setting SESSION_COOKIE_DOMAIN to ".site.com", but it doesn't work for me on localhost/dev servers. How do you get it to work for localhost sub-domains? When I change the SESSION_COOKIE_DOMAIN on the dev server to the production website domain or ".localhost", django auth logins completely stop working (I'm unable to ever login, no cookie is created on localhost).
I think I got a workaround solution, but couldn't use localhost. I could only get it working for a test ".com" domain that maps to 127.0.0.1.
In my /etc/hosts file (on OSX:)
127.0.0.1 test.com
127.0.0.1 sub1.test.com
127.0.0.1 sub2.test.com
Then on my development settings.py:
SESSION_COOKIE_DOMAIN=".test.com"
I could not get this working with plain "localhost", it seemed I needed the ".com" string in there to get it working. So then I could login and have cross subdomain auth cookies using sub1.test.com:8000 and sub2.test.com:8000 in my browser.