We host our ASP.NET applications on two web servers (Server 2003, IIS 6) that reside behind a hardware load balancer. When I look at the IIS logs, the c-ip value in the IIS (v6) logs are ALWAYS the IP address of the load balancer. I noticed in the http headers, there is an X-Forwarded-For header that appears to have the requesting IP address. Is there something I can do to make IIS log this header value in the logs?
I don't know how long it's been around, but the Advanced Logging extension for IIS 7 and up (on Windows Server 2008 and up) offers Custom logging functionality which can be used to gather (almost) arbitrary information in IIS log files, including custom HTTP request (and response) headers like X-Forwarded-For.
I've just today set this up on our server and it works beautifully.
One thing to note: instead of editing the default Log Definition by the name of %COMPUTERNAME%-Server, just create a new one on your site or globally on your server to avoid the exception "The request is not supported." when trying to save your changes. This happens when you try to edit that default definition on the site level (thanks to this thread for the answer).
When going through a proxy you the x-forwarded-for is what is most commonly used by load balancers. You can probably write an httpfilter which will swap this around yourself; or IIS Tracer has the ability to play with the standard files; including swapping the c-ip and x-forwarded field.
If this isnt being done for the use of a third party reporting tool; you might want to dump your logs into SQL Server where you can manipulate the columns whenever you want.
Personally i go for the latter so that i can get aggregate data for all the servers; i dump into different tables in the same db and then report from all the web servers in the farm. I also find it easier than managing 500mb or so log files all over the place.
F5 networks offers an ISAPI filter on devcentral.f5.com that will take x-forwarded-for and use it in the logs.
Beyond that, though, there's not much you can do - this is how TCP works. :)
This is a pretty old question, but thought I'd add that IIS 8.5 has the ability to write
custom HTTP headers to the IIS logs. This is a much nicer option than installing an ISAPI filter or HTTP module.
This walk through shows how to set this up through IIS Manager:
http://www.iis.net/learn/get-started/whats-new-in-iis-85/enhanced-logging-for-iis85
This other SO question shows how to do it with PowerShell:
Add IIS 8.5 Custom Logging Fields with Powershell
IIS 8.5 advanced logging will let you log the X-FORWAREDED-FOR header easily.
IIS 8.5 Advanced Logging
Related
I am running two Windows server 2016s with IIS 10.0.14393. One server for staging purposes, and one for production.
The application has one "front-end app" and one "back-end REST api" running on the same IIS server. The front end communicates with the backend (suprise!). The difficulty I am facing is that the staging server works as expected, i.e no "Sign in" box appears when entering the front-end web page (React). However, on the production server this box pops-up.
When the page is loaded, there is javascript that fetches some information from the API, and it seems that this async fetch is causing the pop-up to occur (the request is in pending mode until login).
I have studied the configuration of IIS on the two servers but can't seem to find any obvious differences.
Both instances have both windows authentication and anonymous authentication turned on for both front-end and backe-end. I need this as the API has different types of authentication for the endpoints.
Anyone that has solved a similar issue?
Thanks
If someone experiences a similar issue the following link may help: https://support.microsoft.com/en-us/help/258063/internet-explorer-may-prompt-you-for-a-password
In my case I was sending the request to the api with the full domain url. The problem was fixed by just using the machine name (and port in my case) when sending the request. If the whole domain with punctuation is used, the system believes that the request is meant for the Internet and not the intranet, and will not include any credentials.
Another, and probably more robust solution, is to add the site in question to: Internet properties -> security -> Local intranet -> sites -> advanced.
I am a newbie at play, and I am trying at least to use HTTPS on a login and sign up pages in order to have more security on sensitive user data.
I have a range of questions regarding this:
I have configured my play application to use https on the application.conf file with the https.port property. However in my development environment I cant seem to start the server with https capability unless I use the command: play -Dhttps.port=<port>
Why does this happen? I would think that I could use a dev.conf (right now is the application.conf) file in order to do this. Can't I start the server in dev mode while using this kind of settings specified on the configuration file?
Although I start the server with https capabilities, what is the correct way to use https on play? I already created a java key store that I use, and tried to redirect (from a controller) requests to a https url using redirect(securedIndexCall.absoluteURL(request, secure)). But it does not seem to work at least on my dev enviroment (localhost). The logs specify exceptions like:
java.lang.IllegalArgumentException: empty text
java.lang.IllegalArgumentException: invalid version format: M¥å/=<junk characters continue>
Should I use https on the whole application, or just securing the login and sign up requests is sufficient?
I feel the official documentation provided is rather insufficient and I am at a loss here trying to figure out how I should do this.
Any help would be really appreciated!
I agree with Fernando, I think it's easier to set up a front end web server. In my case I used Lighttpd and it was fairly straightforward to set up. I'd recommend:
Configure Lighttpd as per these instructions (at this stage, don't worry about HTTPS just get HTTP working): http://www.playframework.com/documentation/2.3.x/HTTPServer
Then configure HTTPS in Lighttpd: http://redmine.lighttpd.net/projects/1/wiki/HowToSimpleSSL. If you intend on buying an SSL certificate then there will be a few more options to set (e.g. intermediate certificate). The following page has more information: http://redmine.lighttpd.net/projects/1/wiki/Docs_SSL
Answers to your main questions:
1) Enabling HTTPS in Play
Yes, you have to explicitly say you want to use HTTPS when starting up
http://www.playframework.com/documentation/2.3.x/ConfiguringHttps
2) The "java.lang.IllegalArgumentException" error message
There might be an issue with the keystore. This SO article seems to discuss in more detail: Play framework 2.2.1 HTTPs fails on connection attempt
3) SSL for login page or whole app
Personally, I would go for the whole app. If you're taking the time to set up HTTPS I think you might as well cover the whole site. I guess there are slight performance overheads in running HTTPS but realistically it's not something you'd notice.
You should use a front end server for HTTPS, and use HTTPS for the whole application.
Please see Setting up a front end HTTP server and see the commented out nginx settings.
I need to host my WCF service but I am unable to decide whether I should host it in IIS or a windows service?
What are the advantages, drawbacks, benefits of one over the other please?
Thank you
IIS under version 7 is out of the question for any serious hosting anyway....
As for IIS7+/WAS vs. self-hosting in a NT service:
the IIS7/WAS setup will "load on demand", e.g. when your first request comes in, a ServiceHost will be created, then that service host creates the service class to handle the request. This is beneficial from a memory point of view (uses no memory for the ServiceHost if no requests come in), but it's a bit of an additional overhead on the first call when IIS first needs to spin up the service host
NT Service allows you to pre-create the ServiceHost and open it so it's ready to handle requests right away; a bit more memory usage, but a bit more responsive, at least on "first calls"
Another benefit of self-hosting: you're 100% in charge of when the service host starts, pauses, stops, and so on. With IIS/WAS, you're at times at the mercy of IIS with its potential to recycle app pools at the worst possible moment......
The main advantages of IIS is that it handles the lifetime of your service for you: activation, recycling...
Its main drawback if you don't have v7 is that without WAS it can only host http based web services
The services need more care in case of fatal error... and then need to be installed whereas a web site can be copied to its web folder once it has been created
If your version of iis is >= 7, then I don't see a lot of interest in not using WAS as it supports all the wcf transports, others might have a different view though...
I'm using the AJAX Test Server in Rational Application Developer. I'm posting a form to another host for authentication. That host takes a URL to redirect to after authentication. However, it insists on using HTTPS whenever it sends the 302 response. The low hanging fruit would be to just use HTTPS locally.
Looking at the launch configuration, the AJAX Test Server appears to be a custom Apache HttpCore server. I haven't spotted anything in the configuration guide.
Is there a way to access this test server via HTTPS?
This is for demo and local development purposes; not production.
Speaking from working with WAS (WebSphere Application Server) in RAD, I'm pretty sure the answer would be yes. The server (at least with WAS) has both secure and "unsecure" ports.
What I have noticed is that when the server is built with the install (at least with the newer versions of the products 7.5+), the ports used are different per install. This is to help with not conflicting with other applications that may use those ports.
So https is probably fine. You just may have to use it over port 302 or some other port.
If there is no admin console for viewing your ports, you could always try the Window | Preferences option under your menu items. Sometimes IBM hides server config stuff in there.
I am at my wits' end on this one.
FYI, I work in infrastructure, not .net development, so I know very little about WCF and next to nothing about Visual Studio as an environment, but I don't think that's where the problem lies.
We have a WCF service running on a couple of IIS 7.5 servers on our internal network. This is exposed to the outside world via reverse proxy on Apache 2.2.15 on Fedora 11. The reverse proxy handles load balancing between the IIS servers, as well as SSL.
The WCF service is configured to use transport level security, and the IIS servers have self-signed SSL certificates. The reverse proxy does not authenticate the IIS servers, and the only reason we have SSL on the IIS servers in the first place is so the WSDL will present the correct location URL.
We thought we had it working perfectly, but there's one annoying and crucial exception: the WSDL can't be added as a service reference in Visual Studio on machines running Windows Vista or later. On an XP machine, it's fine, but anything later throws the following error:
There was an error downloading
'[URL]'. The operation has timed out
Metadata contains a reference that
cannot be resolved: '[URL]'. An error
occurred while making the HTTP request
to [URL]. This could be due to the
fact that the server certificate is
not configured properly with HTTP.SYS
in the HTTPS case. This could also be
caused by a mismatch of the security
binding between the client and the
server. The underlying connection was
closed: An unexpected error occurred
on a send. Received an unexpected EOF
or 0 bytes from the transport stream.
If the service is defined in the
current solution, try building the
solution and adding the service
reference again.
The WSDL is accessible through a browser, or through regular SOAP, on any machine and without any SSL complaints. It's just Visual Studio that has an issue.
Initial Googling revealed that it might be a problem with the cipher suite that VS used, suggesting that VS on Vista or later would by default attempt to use TLS1.0 in HTTPS connections, and if an intermediary device didn't support that protocol, it would just drop the request. This is definitely not the case, though. The reverse proxy explicitly prefers TLS1.0, and even when viewing the WSDL through a browser, it flags up as using TLS1.0 for the connection.
Having pointed the proxy at other functioning WCF services on different IIS servers, the same error occurs, leading me to assume it revolves around the reverse proxy configuration. The trouble is that it seems to be identically configured to another reverse proxy carrying out the same task elsewhere.
It's presumably some transport level issue around how VS establishes HTTPS connections on different operating systems, but I simply don't know enough about it to hazard a guess about what that might be. Anyone have any suggestions?
Well, that was embarrassing.
I'm sure there's some unwritten cosmic law that results in me finding the incredibly simple solution to a problem I've been grinding away at for days about ten minutes after posting it up on StackOverflow.
The ServerName directive in the virtual host config didn't match the URL. It did match the certificate (which has a Subject Alternative Name, so it didn't throw up any SSL warnings), but that wasn't the name I was accessing it with.
I'm assuming there's some extension of TLS1.0 that VS uses which enforces this, which isn't used by browsers or SOAP clients. This is probably useful information for anyone else trying this with a certificate that has Subject Alternative Names. It wouldn't have come up otherwise.