I've inherited a relatively low traffic web application in which the main website is accessible on intranet, however it gets its data from a wcf service that runs on the same server which is only accessible via localhost. It was explained to me that this design was implemented as a security measure - essentially to ensure that no entity external to the server could potentially have access to our service and hence our data. The database however, is usually located on a different server.
It's been ok for a while but I am looking at ways to improve performance and it seems that running queries against the wcf service and having to serialize the response for transmission etc. is a waste of time - I'd like to just access the db directly from my web app.
Is this current design logical? Wouldn't it be better overall (for security, and performance) to have my site access db directly, and beef up the security between the app and the db?
Thanks in advance.
Rusty
I'm not sure if I have the big picture from your description. However, it is a common practise to have web-applications consuming content from more than a service to form a graphical interface to end-user. With the grow of SOA, this allows for fast integration to combine sources (from services) and producing rich output. This is called Mashup
This also, amongst other things, enhances the security of the backend services as they are only accessed by the backend application server, and not directly from front-end client
So, from an architectural perspective, it seems your application is trying to do this.
Having the services on the same server, and only consumed by the local server (localhost) is a choice taken to prevent but the application server running on the same machine from having access. This could be due to lack of better control on network access and network zoning
Your database lives on a different server, where there could be another measure implemented to secure the traffic and access
In general, implementation of security requires a budget, as any other functional and non-functional requirement. This is usually associated with the risk you're exposed to, and the sensitivity of the information. The earlier the security is built into the overall architecture the better.
Accessing the database from your web-application requires best practices to protect against the many risks of intrusions and vulnerabilities. In general, your web-client should NOT access the DB directly, and should always use server-side services and validation to do so, be it through wcf or other means
Related
I need some help for a noob programmer. I have an application I built > assetcat.app
I am venturing into the depths of networking and looking to rebuild the app using a host / client system.
I have been building the foundation for this with WCF. But it has been a struggle with roadblocks at every breakthrough, I expected to get simple host/client environment with authentication setup no problems. But I have had issues with the network access on different IP's, certificate issues, and even just finding information on MSDN that shows example that doesn't use the app.config. As I need to do most stuff dynamically for portability.
I'm sure if I continue with WCF I will succeed but I'm starting to wonder if there is something more simple. It seams WCF is more suitable to some kind of in-house development were the company of the app also runs the server.
What I want to be able to achieve:
-User installs and manages their own instance of the server software.
-They create accounts witch anyone who downloads the client can point to.
So Bob wants to make a game and is working in a team, Bob installs the server app and sets up some user logins. Bobs team mates install the client app, set the pointer to the IP of his server app, and login. Everyone in his team enjoys access to content managed by the server app.
In this situation, should I continue with WCF? My concern is also around certificates, from what I have gathered I can just chare a development certificate for everyone to use. Each person who installs the server software is also going to have to create or buy a certificate? That seems like a whole lot of mucking about that nobody is gonna do.
WCF has been around for a long time and before what APIs generally look like today. WCF like SOAP/WSDL allowed for strongly typed contracts and in general (before JSON was a thing) shared messages via XML documents. Many enterprises still have WCF services for integration points.
Today, the modern trend is to have less strongly typed contracts, and share messages via JSON payloads. Rather than SOAP/WSDL endpoints you have basic HTTP listeners that can accept requests (usually POSTs) and parse the JSON to business objects. Many folks prefer to create stateless and Restful (or Rest APIs) as this aids with scalability and fault tolerance.
WCF would seem like the wrong way to go for game development. Restful APIs can still use transport and message encryption, but be a lot lighter weight than WCF which adds a lot of overhead and complications (contracts etc) that you probably dont need.
In terms of encryption, you could add SSL/HTTPS using a Let's Encrypt certificates. These are free to obtain.
I have currently built application in which I handle Products, Accounts, Orders, etc.
There are two databases one is a database which I created where I handle Users and Roles and some minor Application specific data. The other database is external and it is the one which holds all the data about Orders, Products and Accounts.
What I am trying to figure out is: how to build a server which runs parallel to the main application and handles all data manipulation with the external database.
Let's say a situation in which this would be helpful: There is an excel file which has to be created based on big amount of data and afterwards it has to be stored in the externalDB as certain type of format and sent as Email to someone. This will surely overload the main thread of the main application, hence we don't want that. Therefore, it would be a good idea to handle those kind of situations outside user's vision.
I am using ASP.NET MVC 5 and was curious what would be a good approach for this situation? I was thinking that I should make Console application, which is working as a service.
You would create a service architecture and have the services communicate with each other through controllers. These could push data back to the main application views, or the views could request data push from the services.
If you wanted to have jobs etc running on that server that send emails, you could easily just create SQL jobs or SSIS jobs or even custom service jobs that did that based on your criteria that are separate from the main view (where view is the main application that the user interacts with)
Services themselves could be configured with a light User Interface that you could call up on the server, perhaps in the service tray or through the Services component of Windows.
SOA architecture
https://www.cleverism.com/how-to-build-service-oriented-architecture-soa/
Micro Service architecture
http://microservices.io/patterns/microservices.html
Hope that helps. Good luck!
There are quite a few ways to do these kinds of things.
If your applications are for Android or iOS devices, it's common practice to have an external server running which handles intensive processing including managing your excel data, sending emails and database communication.
If your applications are cross-platform desktop applications or OS-specific desktop applications, you can still be able to use the external server, although certain other parts of the processing may be done on the client machine.
By using a web service to deal with database communication, it makes the applications more secure in regards to hard-coded database connection information, SMTP server credentials etc.
Using a RESTful web service will mean that you're adhering to the Hypertext Transfer Protocol (HTTP) which is great for exchanging data in the majority of cases.
Using a console application which acts as a TCP client server allows you to use the Transmission Control Protocol (TCP) to communicate in a different way. You're able to pass on data in a custom format if you wish. You'd be able to create a standard for communication which your applications will need to stick to.
The console application would do the same processing as the web service, however you would be in full control of logging requests, responses and data transfer.
I have a public server with web services (.Net) that collect data and uploaded files from different mobile apps and I need to synchronise it with an internal intranet server.
The intranet server is deeply protected by firewall and organisation policies.
I think this is a pretty common scenario where messages and brokers could be used, something like Rabbitmq or Nservicebus, but I'm not an expert on it.
As the data is only to be sent from the external server to the intranet one in unidirectional and asynchronous way I was thinking not to add another layer of indirection to the architecture and just use the web services exposed also for server to server communication.
The approach would be like:
An intranet windows serivce would poll regularly and at different scheduled intervals the external web service to know if there is new data to get (maybe from a certain point in time)
The web service would respond with the list of the new data and files
The windows service would iterate with calls to get all the data to be inserted in the intranet and download the uploaded files.
What are the risks of this approach? Would be better that the external web service would respond only a link to a huge zipped file response with all the data and files in it?
Should I use a something like RabbitMq also for a so simple scenario?
If you are literally dealing with files, you might want to think about something even simpler. FTP (more specifically sftp) might fit your needs better, and be FAR simpler to implement.
I'm new at Visual C# and the .NET framework but have a fair amount of experience in LAMP development. I was wondering about the security of linq to sql communication.
Usually when doing it the LAMP way, measures such as using a service layer were used partially to increase the security of the system not exposing the database authentication details over http.
Having gone through a few recommended (by microsoft) linq->sql tutorials, it seems as if the client-side application (through a web application) is interacting directly with the database. This doesn't seem very efficient or secure....
I would like to know the following hings:
1) What measures exist in .NET to allow for secure communication between client-side and server side apps?
2) Are there any preinstalled service-layer frameworks to work with in .NET?
3) Is it possible to manually use http request methods (POST/GET) in order to send data from a c# web application to a remote SQL Server database?
In an ASP.NET application all the C# code you write is executed on the server(server-side), and after it is executed the page is sent to the client(browser). Client-side code refers to javascript. Database details are not sent to the client.
You could refer to a LINQ system as a "client" in relation to the database, but that would be like referring to the PHP part of a LAMP application as the "client" in relation to the database - completely true but slightly misleading. In terms of the overall client - the browser - LINQ no more exposes authentication details than LAMP does.
Which "client" do you mean here. In terms of the browser the main mechanism is that the browser doesn't know what on earth you are doing. It won't even know it is LINQ unless you're the sort of person who likes putting "Powered by..." images on your webpage. In terms of the client to the database, there are several authentication models (user/pass, NTLM, Kerberos and I think some more) and you can use SSL and IPSec on the connection between the webserver and the database server.
You mean like MVC and WCF?
Yes, there has been since SQL2000, see http://msdn.microsoft.com/en-us/library/aa226553%28v=sql.80%29.aspx though I don't think it's very popular. This has nothing to do with LINQ which would connect to SQL through 1433 using its native protocol, and perhaps be used to build a website that allowed restricted operations rather than manual manipulation of server over HTTP.
I m planning to build another layer between application layer and database layer to reduce database access.
There are 200 hundred application servers and a single giant database server.
I wouldnt like 200 servers to query the db server. therefore planning to build another layer between and cache the data in this later, like cache farm. Servers in this layers will periodically query the db and cache the results in the service layer and clients will query the WCF servers.
I m not talking about distributed cache, which i already have.
I m not familiar with WCF, would it be a good option to implement for this purpose?
Would u recommend REST ? or web service?
WCF is the new standard for web (and other) services on the Microsoft stack, and it also suports building both SOAP-based as well as REST-based services.
It's also well suited for handling both internal (company-internal LAN/intranet - using fast and efficient TCP/IP communications) as well as outward-oriented services. It interfaces with Windows Azure and the cloud, if you need to support that. It interoperates with any SOAP or REST client, it's highly configurable, highly extensible, and all around useful and offers a unified programming model. It can interface with message queues, if you need that - all with the same programming experience.
Based on WCF, you can easily define your database models and expose those as REST-based OData feeds - you'll be putting your database out on the web in minutes (if you're adventurous and wish to do so .... but it's at least possible!).
So: YES! WCF is definitely the way to go!
As for resoures: there's the MSDN WCF Developer Center which has everything from beginner's tutorials to articles and sample code.
Also, check out the screen cast library up on MSDN for some really useful, 10-15 minute chunks of information on just about any topic related to WCF you might be interested in.
Standard SOAP web services are as easy as falling down when using WCF and you control both the server and client.
All you need to do on the server side is define your operations contracts and data contracts, and the clients will be able to build proxy classes for accessing your web services automatically.
There are some things you need to learn when defining your operation and data contracts, but once done, a client can VERY easily poke the service at design time, access the generated WSDL, and automatically generate a proxy class for accessing your new operations with their data contracts.
I would very rarely use REST as the primary interaction mechanism between application servers and database servers. If both ends of the interaction are controlled by you and live in the same data center and can be updated in sync then the extra work required to create a RESTful system would likely be wasted.
Personally, I would be more tempted to look at a messaging type system. Something like nServiceBus.