I have an issue with a SignalR application that works fine in our Dev environment but not in Production.
This application runs off Javascript and attempts to connect to a Windows 2012 R2 server (IIs 8.5, .net 4.5) with a Websockets connection.
In our Dev environment the Websockets connection works fine, but in Production it will fall back to Long Polling. Both servers have the exact same webconfig file.
We've pulled the Production Server out from behind our load balancer to verify there is no interference there and I've also verified that the VLAN the production server is on won't block any traffic
Websockets is definitely installed and enabled on the Production server, and the IE settings on both servers are exactly the same.
I run a very similar setup with no issues in our a Dev environment vs. Production with a load balancer.
You mention that your webconfig file is the same, but on the 2012 server have you verified that Web Sockets option is installed and enabled?
Had a similar problem (except worked in prod not dev). Even though the web.config was the same, I had to set <httpRuntime targetFramework="4.5.2" /> for websockets to work on both environments.
Related
We cloned the servers, upgraded to a newer version of the OS (Windows 2012) which is compatible with the web app. However, when we placed those servers in production, only the one with the load balancer was being accessible through the IP. The other 4 were not because the load balancer was trying to redirect traffic to the local IP instead of the public ones. I don't know if this is information enough, but we can't seem to find the issue since the config of the web app is the same and the IIS didn't seem to have issues. Maybe the DNS? The IP's are the same.
We are trying to reproduce the load of production IIS server in our development IIS server (to evaluate the impact of changes in database indexes)
I dont know is its possible to record the IIS traffic on production server to them send this traffic to development server.
Neither knows if this is the correct approach to acomplish this task
Can yo help me? Thanks
PD: We are using Windows Server 2008 SE
It sounds like you need reverse proxy with URL rewrite. When you build reverse proxy in production server, Production server will record requests and will traffic all requests to your development server.
So please install Application request routing and URL rewrite then create reverse proxy rule to traffic requests.
https://learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing
I have developed a Jooby-Application which is hosted on a netty server. I can access the application on localhost and tests were fine. Now I want to make the app accessable over internet and dont know what is the best way to reach this goal?
The complete application is hosted on a Windows Server, because it uses Excel. (Read/Write over Apache POI. For macros it has to be Windows) Should I try to connect the running netty-server with IIS or can I just forward the requests from outside to localhost? The last mentioned approach propably is a bad idea regarding security issues.
It works with reverse proxy over IIS. I had to install some features like Application Request Routing and URL Rewrite. Then I can start the jooby application (netty server) as usual on a specific port at localhost and set a reverse proxy to it.
I am not sure why being on a window is necessary, anyways, Netty is just a Java network programming framework, it can run on any platform where Java is installed.
You need to host a server, you can buy a VPS, install windows as OS, install Java, you can run your application as you like.
What I understand is you need to test it, for that you can use any port forwarding service like https://pagekite.net/support/intro/features/ to enable "world access" to localhost
Hope you're all doing fin!
I'm working at a company where the main application is at a web page made with Java. It deploys with Tomcat on a server with Microsoft Windows Server 2008 R2 O.S. I've recently made some changes on this application, but the development environment is not on Tomcat but on JBoss and the former developers knew how to deploy the development from JBoss to Tomcat, but didn't leave any documentation on how to do that.
My problem is that the DNS server is associated with Tomcat, so my development deployed on JBoss can only be accessed through IP address.
My team and I spoke to the company in charge of the DNS server and it indicated that Tomcat's configuration as DNS response should be made by us, given that this company is only in charge of redirecting the IP without specifying the web server.
In order to solve this problem I have two proposals which I don't know how to implement:
1. Modify the server configuration in order to respond to the DNS server through JBoss, overwriting Tomcat response.
2. Deploy the application made on JBoss on Tomcat server.
I would really appreciate your help with any of these proposals. It is a very important matter for the company.
Thanks a lot beforehand for your help.
I'm a web developer. I used to work in an environment where I could build entire production web sites and run them in local IIS for debugging purposes.
I recently switched jobs and now that's not allowed anymore. Security policy (please don't ask about it) does not allow for me to run IIS on my development workstation. However, it seems that there is no reason why I may not attach a remote debugger (msvsmon.exe) to the IIS running the development web site because it is not public-facing (neither is my workstation public facing, but let's not talk about the security policy that I have no control over).
I would like to know what security concerns there are for using the remote debugger. The documentation says that UDP port 135 must be open between the remote development workstation and the web server being debugged...
Is there any particular security concern that I should bear in mind?
The only security concerns would be internal traffic sniffing on that port in case https traffic was being debugged and the unencrypted values were part of what was being debugged this data would likely go over the wire unencrypted.
Also, the vulnerabilities in the service that receives the UDP packets could be futzed with (again internally) to gain access in a way that would normally not be available (UDP port listening off).