I haven't found much discussion about this...
Most signalr samples I have seen would send and receive via a designated port like 5000 or 8080
I have a need for chatting in my app. My asp.net backend site does more than just handling messages between users, so it doesn't make a difference for me to host another page for that in the site my iis.
I understand the difference of having the signalr self-hosted or hosted normally in iis... If I have it hosted by iis, so my users will access the page normally without a port, would that make a difference? Is there something internal in signalr that is preferring the use of a port? What are the pros/cons of using ports with signalr?
SignalR has no preference for a specific port. When no port in specified in the URL then the port is implied from the protocol, e.g. HTTP uses port 80 and HTTPS uses port 443. So there is no concept of SignalR without a port.
I would think that the main reason for using SignalR on a different port than the rest of your site is that you can host SignalR independently of your main site without any interference in URL's etc. On the other hand, using a non-standard port may give you problems with restrictive firewalls that only allows traffic on port 80 and 443 to pass. When using a different port for SignalR you also lose the ability to use relative URL's to specify the SignalR endpoint.
Related
I want run multiple ASP.NET websites on a single IIS server using the same IP address and port (80).
I cannot use host headers to accomplish this because my clients have not agreed to use a domain name.
My websites will be accessed using an IP like 227.23.32.44. All of them will use the same port (80). The reason for this is, I have around seven applications and my clients wants me to use standard, IANA approved, easy to remember port numbers.
If I want to go with standard, IANA approved TCP port numbers, I would be left with
227.23.32.44:80
227.23.32.44:116
227.23.32.44:84
This is not very user friendly.
Rather, if I use
227.23.32.44:80
227.23.32.44:81
227.23.32.44:82
Then it is much more user friendly but my clients will not let me use this.
Is there any other way to run multiple websites? Can I use another proxy server to inspect the url of all incoming requests and then route to the necessary application? I have heard about nginx. Can I use nginx to do this?
You need to uniquely identify a site using a composite key of IP+Host Header+Port.
Since host header is out, you are left with just IP and Port. You have 2 options.
1.Have multiple adapters so that you have multiple IPs and port will be 80.
2.Have same IP but different Ports
Host header is meant precisely for this reason. You can have same IP, same port but different Host header.
Nginx is not a silver bullet either. You won't be able to run ASP.NET on Nginx.
Why not to put applications in different folders on IIS?
227.23.32.44/WebApp1
227.23.32.44/WebApp2
227.23.32.44/WebApi
IIS support this out of the box:
Go to IIS Manager
Right-click Default Web Site
Choose "Add Application..." command. Alias means customer visible part of URL.
I have a Asp.net website hosted through Ultidev, and am using DynDns to assign a hostname (web address) to the site. My question is, is their a setting or configuration or something that I can change to go to www.yoursitename.org and my page load? Or must you always specify the port to connect to in order to connect to your site www.yoursitename.org:12345
Assuming you have already configured your router to forward port 80 (standard http port) traffic to you host computer, and opened PC firewall to allow inbound port 80 connections, then what you need to do is to run "[UltiDev Web Server Explorer][1]" and there add combination of the www.yoursitename.org and port 80 as shown on the screenshots below. One thing to note that if port 80 is already occupied in the exclusive mode by an another web server (Apache, etc.), you will see that when saving UWS configuration, the www.yoursitename.org:80 will disappear. If it didn't disappear, then the site:port combination was available and now will be used.
I've developed a web app, which uses HTTPS and which works fine when I access is it (live). Yet some customers, who use proxy servers, can't access the site. I already tried to use a real certificate (a cheap one and only a trial, but yet valid), but that didn't help.
Everytime one of these users tries to access the site the browser tries to load it until a timeout occurs. One user even was shown an authentication (but I'm not 100% sure if this was due to a proxy, still waiting for response from the customer)
For which reasons can this happen and what can I do about it?
I'm using IIS, ASP.NET (C#) and JS. Sideinfo: The URL contains a port, the internal structure of the network the IIS is running in (not mine) doesn't allow it otherwise.
443 is dedicated port for HTTPS connectivity. Add type 'HTTPS' with default port 443 in Site bindings of hosted site directory. Check after whether SSL is enabled or not? in IE(browser)->Tools->Internet options->Advanced->Security.
If the HTTPS port in your web app's URL isn't port 443, you'll have a problem with corporate proxies that don't like non-standard HTTPS ports.
i.e. I hope your URL looks something like this: http://example.com:443/...
I developed an FBConnect web application using C# .Net Framework 4.0 recently. Tested with my UAT server, everything just works fine, I'm able to login with my Facebook account, and perform all operation.
Unfortunately when I deploy the same code to my client's production environment, the FBConnect return "unreachable network 69.171.229.24:443". After several investigation, notice the port 443 is blocked! And due to corporate policy, this port is not allowed!!
Is there alternate way I can tweak my facebook app settings NOT to authenticate via port 443? instead of rewriting my code?
Please advice.
No, there is no alternative.
Port 443 is for secure HTTPS connections using TLS and SSL. Facebook, quite correctly, restricts access to their authentication mechanism to this port: (as far as I know) there are no alternative mechanisms that use a different port or an insecure login on port 80.
Check with your client to see if there's an proxy server that can be used for HTTPS connections.
Otherwise, request that your client opens that port.
Is it possible to have a FTP server using SSL on a application server that does not use SSL?
How would you setup an ASP.NET 2.0 to consume a SSL certificate?
This certianly sounds possible but is it advisable, is it good practice?
The choice on using SSL us made on a per connection level, usually determined by the IP port being used (i.e. will be set up between client and server before any application code involved).
The same service/content could be set up on multiple ports each with a different choice for SSL.
The certificate is per host name, but servers can generally support appearing under different names.
To use SSL with ASP.NET takes nothing special, it just works once the IIS web site is configured to support SSL (or to require it: when connections to port 80 for HTTP are redirected to the SSL port); this choice can be made on a per folder basis.
FTP is at the application layer, and SSL is lower, at the presentation layer. The SSL sessions are on a per connection basis. Take a look at the Wikipedia page. The SSL connection is established before anything happens with your application. Your FTP server probably isn't running inside your .NET application server, is it? You should be able to setup an SSH server listening for SCP connections separately. If it really does run from inside your app server, you should be able to listen on a separate port for the SSL connection.
Short of any of that, heres a good link for configuring SSL in IIS. You don't have to make the certificates mandatory. That way you can allow unsecured traffic and secure traffic if that fits in with your application model.
While protecting an application with SSL is always a good idea, it is technically not trivial.
Having a web application protected with SSL requires the webserver to be reachable on a new port (443/https instead of 80/http). This has to be configured "system-wide". Also, there may be only one certificate per IP-address, which is often a problem when hosting multiple domains on the same server.