I have a web service on iis that i'm calling in a simple console app
this web service is takes stuff out of a database
I changed the data base on a config file but it seems to still be calling the former data base
any tip?
If there are some cached database credentials within the application, simply recycling the application pool for which it is in will flush that out. If you're not familiar with the application pools, simply restart IIS and that will do the same thing.
If you don't have credentials cached, could you specify where the credentials are being stored, such as a web.config file, custom library, etc?
Make sure that the connection string is actually being used rather than it using the settings from the original dataset designer.
If you have used the dataset designer there will be a connection string setting in the settings file of the project. unless the connection string in your web.config is exactly the same then it will use the original.
You can check whether it is using the string you supplied by entering garbage in the web.config connection string and seeing if the webservice fails after you have restarted the website.
Hope that helps.
It's hard to offer this advice without sounding unhelpful, but in cases like these you just have to track through it, logging out the various important bits, like what connection string your components are using when they connect to the database, etc, and the answer will sooner or later come to light. I say this from experience.
There's not much that myself or other posters here can do but offer you the most general advice, like recycling the application pools. Your question is just too short and lacking in information, and the subject of web services is a very wide one.
So start by adding logging as I suggested and it might just work, or at least give us more to go on. All the best to you..
Are you setting the connection string in the client app.config or the web services web.config?
Related
I am working on a project that involves a web application and two services. The two services each have their own job. One kills an entry in the application by marking it as dead in the database and removing it's "query string" from Splunk. The other is a reporting service. Every day at 5pm it sends out a report of all the active entries in the DB.
My issue is that these need to be installable on client servers and thus the IP address for the DB and the Splunk Server will be vary. Originally I was planning on encrypting the settings inside Settings.settings under the property folder. In the service's command line installation functions I tried putting Console.writeLine and readLine but after running that and doing some research I learned that Console output is discarded for services which leaves my settings empty.
What is the best practice to create an interface to configure a service?
As any other .NET application the best way of configuring a service is via the app.config file. This file is renamed at compile time to yourappname.exe.config. You can the use the information contained with ConfigurationManager class.
For password encryption, have a look at this other SO question: Encrypt password in App.config
You could add a simple Winform/WPF UI project to your solution and have it tweak/encrypt the service's .config file through SectionInformation.ProtectSection
It could be useful that it would ask the user if the service should be restarted when changes are done through the UI.
I have created a forms application for my project. I want to host on my website for users to download and test it. Because I am using a configuration manager I have to include the config file along with the .exe as there is a back end remote database for the application. And of course I only now realize my connection string is there for all to see. I tried renaming the app.config to web.config, but the aspnet_regiis -pef command just returns a help menu when ran as admin on my vista machine! Even if this command works and I rename web.config back to app.config, will the machine which runs the app when downloaded automatically decrypt the connection string? So in conclusion what is the best way for a novice like to approach this dilemma? Why does aspnet_regiis -pef not run? I have also looked at other posts about this topic but unfortunately they have not worked for me so far.
Either create user/specific connection string, or wrap all your data access in some web services, where you can control the autorization.
Creating user specific connection string is the simplest, but may have impact on the DB charge. You can still keep one connection string, but using windows identity to connect. In both case, you will have to spent some effort to ensure users won't able to do more than what they are allowed to do.
Wrapping your data access in web services is far more manageable but will require an extra work to make it works. Maybe you can take a look at RIA Services. The advantages are multiples: you can control the permissions within the web services, and you are reducing the exposure of unwanted queries.
Please also note that even if you encrypt the connection string in the configuration file, any malicious user will be able to decrypt it. A simple decompiler will highlight your decryption key.
You could just store an encrypt the connection string in the app.config but you will have to include the encryption key somewhere in the application. Therefore this is not safe because everyone can just decompile the application or attach a debugger and extract the connection string. Or monitor the network traffic. Actually there is now way you can prevent this from happening - whatever your application can do can be done manually by everyone (with access to the application).
The flaw in the design is that the application needs direct access to the database in the first place. It is close to impossible to ensure that the database can not be corrupted in this scenario (unless the database is only used for reading data). Essentially you would have to replicate a large portion of your business logic at the database server to ensure that no sequence of requests will corrupt the state.
A better solution would be accessing the database only indirectly through a web service. This allows you to perform better and easier to implement server-side validation and even authentication and authorization per user.
I have developed a .Net 3.5 windows forms application. I also want to design a website that has a webservice with multiple Webmethods to query the database on the host machine. I want the webservice to be called ONLY through my winapp and my website! And I don't want any other people to be able to call and use my webservice but only some people who have access to the windows application that I have developed.
I need a good security scenario for this! I truly appreciate anyone who can help me because this is my first experience of developing a webservice and I really need it to be as secure as I mentioned!
What you're talking about is going to be difficult to do for several reasons, but primarily this:
If you put anything in code on your WinForms app, it can be decompiled very easily. You can obfuscate the code all you like, but it can be de-compiled.
Because of that, any code that you have in your app can be read by anyone with access to the code. You should always treat any WinForms app as if it's completely compromised, and ensure that the security at the server end compensates.
Because of this, you can't simply store usernames and passwords in configuration files or in code. You have to come up with something else. You CAN use authentication and prompt the user to enter a username/password on program launch, and use that. However, people tend to share these things, so you may want to go for extra protection.
You can put the connection info, or secrets into the app.config and encrypt it, but anyone who can de-compile the code, can recompile it, and add code to decrypt it at will.
You can provide signed keys with your app, and use that in an authentication mechanism, but that can be bypassed.
You can restrict your IP address to specific IP addresses, but those can be spoofed.
However...
By layering all of the above techniques, you can make it difficult for an attacker to bypass your precautions. We did the following in one of our apps where we had a similar requirement:
We set up a database that holds a GUID record for each authorized customer, and IP addresses allowed for that customer.
Every web method expects a CustomerKey parameter. (the guid mentioned above) Each call to a web service checks the key against the IP address.
If it matches, valid data is returned.
If it fails, valid looking data is returned. We actually return what looks like good data, but it's really not. This makes it harder for an attacker to know if they've actually broken through the defenses.
In the WinForms app, the key is stored in the app.config, which is encrypted in the main() event (the entry point for WinForms apps). This is to prevent the casual reader from accessing it.
The program is launched automatically on install, so that the encryption happens at startup, to minimize the chance someone can read the file before it's encrypted.
Also, the code is obfuscated.
Layering the defenses, hopefully, will discourage the average attacker.
Microsoft has some guidelines as well: http://msdn.microsoft.com/en-us/library/ff648643.aspx
I'm hoping someone can help me understand a process of recycling a webservice using the following method:
At the company where I work, the process is to simply open up the web.config file in an editor, make any kind of modification, and then save the file. The modification can be as simple as entering a space after the last xml node and then removing it.
I'm curious, but how does this end up "recycling the webservice"?
ASP.NET has a file system watcher on the config file. From there it boots the application from the app pool/app domain.
A better practice would to set up different app pools and recycle them from IIS.
Updating the web.config actually recycles the application pool for the web services/sites. It also clears out the application cache and session variables if used InProc.
This isn't the recommended approach though because if you make an oopsie then your webservice won't come back up. Its better to go to the IIS application pool manager and recycle it from there.
i will develop utility program for a company with more than 1000 client and the program must be win application with .Net because my program will act with another program.
What is your suggest for place of app.config?
one scenario:
We put the app.config on the server that configured once and write a windows service for it that publishes the connectionString through TCP/IP Socket.
In Socket programming we don't need for anything because we just use a free Port for send ConnectioString from server to clients. My Scenario based on this approach. (Default port embedded in app).
Reading your question (I am deciphering a bit) I can see that clients may be separated from eachother, and even if it's just in the LAN, the following solution would work:
Develop a WebService whose only job is to give the ConnectionString when called.
This enables you to have an "easy" and robust way of doing this, and could implement it only on the local intranet for security.
Regardless of this, make sure you encrypt the Data and perhaps even RSA sign it good measure. This will give you a secure, robust and less time consuming solution to your problem.
The app.config belongs with the client app - I wouldn't even try and hack together something else. Ship it as part of your app and install it. Especially the connection strings cannot really be outsourced anywhere else.
We use a hybrid scenario where we have just about only the connection string in the app.config on every client, and anything else that needs to be configured is in a database table which everyone reads.
But the connection string can't really be centralized in the database..... how would you connect to the database to read the connection string then? :-) A classic "chicken-and-egg" problem.
So: just use app.config and put your connection string there (if needed, encrypt the <connectionStrings> section).
The only viable alternative would be to embed the connection string into the app itself - as a constant string in a "Constants.cs" file or something.
Marc
The ideal architecture would be to provide a service that acts as your data layer - your WinForms application would make calls on this service to perform all its interaction with the database. Not only does this provide an abstraction layer for your data access, but it centralises your data connectivity into a single area (your data service), so you can store your connection string securely on the server that hosts this data service.
If you want central configuration, I would put the configuration into Active Directory, under the CN=Services, CN=Configuration node.
I use an adaptive connection string that configures itself based on the network and/or machine that the application is running on. I wrote a blog post about this approach some time ago. The key is to override the SettingsLoaded event to reconfigure the baked in connection strings. This will work on any .NET Windows client application or DLL. I even used this technique within DLLs to control the connection string for web applications. It really makes deployment a snap!
Of course this is not the best approach for all scenarios. One drawback is that users and administrators can't change the connection string with the configuration file.
On your server you will have IIS, you can define a url http://myapp.myserver.com and you can put an xml page there, wherever your clients can be, when they start, they can query http://myapp.myserver.com/myapp-config.xml , and on this file you can store version, connection string etc.
And you will have to manually instantiate all variables that you intend to load from this xml instead of app.config, but its not difficult to store your connection string in your program in static variable initiated after reading myapp-config.xml
Shipping app.config at client's place is not good because in case if you need to change any values, change server or distribute load, it will be difficult to redistribute everything.
Instead you can also keep a check on version of xml, if version changes, you can notify to download new version from same server and upgrade their program.