There is an intranet based ASP.NET application that is deployed to a server (IIS) and a group of clients (about ten). The end user can then decide to either connect to the local application (deployed to their local machine) or the server version. I do not understand the reasoning for doing this. My question is: is this common practice?
yes, it is a common practice to verify the performance of the application. Each client will have their own settings and as per process, application should not break in any kind of environment. it is always beneficial to put a server version and a local version.
If the clients are laptops, and the application supports disconnected data sets and synchronization, it would make sense. Typically you'd see something like this when the client machines are taken off-network to be used at a remote work site.
Related
Situation
So I'm thinking about building ASP.NET Core website to host it on Linux based hosting provider. But I still want to use MSSQL database, so best choice for that would be Microsoft Azure.
My Question
Now my question is rather security based, since I know, that hosting them on different providers is totally possible (Regarding this question)
But if I'm about to do so, then how will be my data encrypted? If I'm about to use default HTTP protocol, then I asume, it's not, but if to use HTTPS protocol, it should be encrypted as well? Or how would it work, do I need to setup some other protocols or security for that matter?
My Thoughts
Since Client won't be directly connected with Web Site to Database connection, then there is not chance, that this connection would be listened, yet this "might not be listened" is rather not a far chance. And if HTTPS is included, then all connections should be encrypted, then it should work same with Web Server to Database connection.
You can access Azure SQL from anywhere as long as IP address is in the firewall rule. Since communication to Azure SQL is on SSL/TCP at all times, data is already encrypted.
Ideally, you want to host Azure SQL and web application in same region not to mention same provider. The main reason is your website will be dramatically slow due to network latency, if you host those in different location.
Recently, Azure offers App Service on Linux. It is definitely worth the try, before considering an alternative route.
FYI: Web Apps on Linux does not yet support deployment of .NET Core apps from uncompiled source. You need to publish/compile your .NET Core app locally first, and then push the published site bits to your app.
I have a nettcp service which I have to host. I have three options -
IIS 7
Windows Service
A console application
I would be grateful if anybody could give some valuable thoughts on which option is better vis-a-vis other one.
Here are some of my observations:
IIS 7:
Pros:
Ready made hosting environment inside IIS
Will work with pretty much any hosting environment
Cons:
HTTP Only
Configuration slightly more complex
WAS:
Pros:
Ready made and familiar process model to that of IIS
No dependency on IIS
All protocols supported
Cons:
Not all shared hosting environments will support non-http protocol bindings or unusual port numbers.
Configuration slightly more complex
Windows Service:
Pros:
Starts when windows starts
You can start/stop the service via the service control manager
All protocols supported
Cons:
Some extra steps to deploy/re-deploy (installutil)
You need some extra boilerplate code to support the service implementation
Not ideal if you can't have access to the server to install (e.g. shared hosting)
Console Application:
Pros:
Fast and simple to deploy for testing purposes
All protocols supported
Cons:
You need to be logged on to start the process
Loss of session or machine shutdown will kill the service
Console/RDP access required
We have two servers, both are containing a local application connecting to local web service, applications and services are identical on both servers.
One of the servers work just fine,
The other one is just dead, I have impression the the security configuration are different on those servers.
What prevents an application X from connecting a web-service, given that another application y on the same server can connect to it. and X is a windows service.
What I should check, what is chances?
Thanks
Check if there is any firewall that might need to some ports opened up.
Could there be any kind of AntiVirus or similar set up on one of the servers?
Basic troubleshooting of loosely-coupled applications means independent testing/verification of those services.
Can you access the web service locally through a different application, i.e. a web browser? If you can't reach the service through the browser, then the server configurations (at some level) are not identical.
Only after you're certain the service is reachable should you look into issues with the windows service.
I was planning to have my web application on one server instance, my sql (express) on another instance and a separate domain controller on another. The purpose to allow the asp.net application to access sql server under windows security. This is hosted on a cloud server. Am I getting any security benefit doing this considering its on the cloud server? For example, each 'machine' will have Remote Desktop active.
If it is better than keeping it all on one server instance, what else can i do to maximize security?
Well, separating servers out such that if one is compromised it doesn't lead to a compromise of all your data is a good thing, definitely. That's the main advantage you are getting.
You need to make sure, with the separate layout, that your SQL box doesn't allow connections (to the SQL server) from just any old IP; only the Web server (And, obviously, your external firewall would block that port anyway).
As to what else you can do? Perhaps ask on the networking forums. Many, many things come to mind :)
I would like to be able to step through an application deployed to a remote location which as yet has nothing bar version 3.5 of the .Net framework.
What steps do I need to go through to achieve this and how long would you envisage this taking?
How to: Set Up Remote Debugging
Screencast for Visual Studio 2008 - Remote Debugging with MSVSMON.EXE
This is also a good KB showing some troubleshooting scenarios..
If you have unrestricted TCP/IP access to the remote location, this will be very easy (as in, 5 minutes tops to get it to work): see How to: Set Up Remote Debugging and How to: Run the Remote Debugging Monitor for the steps involved.
If your development machine is separated from the remote server by firewalls, routers, etc., things get a bit more difficult. Since remote debugging requires Windows authentication, DCOM and other things that are usually (and quite sensibly) blocked by security policies, you'll most likely require some kind of VPN access to the remote network in order to get things to work.
Setting up a Routing and Remote Access service on the target server is a quick way to get PPTP dial-in access to it, but there are significant security implications to doing this. So, this is most likely the step that will take up most of your time (and, depending on the organization that manages the target network, lots of discussions with their network/security people...).
My advice would be to start testing with remote debugging using a test machine on your local LAN first, and deal with the connectivity issues once you're comfortable with the basics.