I'm developping an application that I should give to a person only to test its functionality, and I don't want him to have the code.
I also do not want to host the application and give him a remote access.
what should I do?
You could use ioncube to encode your sources before passing them on to your client.
You can save your client the trouble of setting up a server by hosting the app yourself and using .htaccess to password protect the app and/or set up an IP restriction.
Related
Im currently in the process of exposing our internal CRM system to the web so our employees can use it outside out network. The data is being surfaced to our web application via asp.net WebAPI.
We have SSL setup on the website. But am thinking how else I can make sure the WebAPI is secure from malicious use. My ideas are:
Tracking what IP addresses are accessing the WebAPI and only allow addresses that we have validated are from employees. Problem with this having dynamic IP addresses we might be constantly updating a data store of valid IP addresses.
The user has to login to the system. So every request to the webapi will send across their login details which will be validated before the webapi will process any request.
Pass the device ID of the device using the webAPI and validate (pretty much the same as IP Address tracking in idea 1)
Having a unique clientside generated access token which much match up at the server side.
Has anybody got any advice on my security ideas I outlined? Is it to little or is it overkill?
Just want to make sure the data cannot be hacked, because my butt would be on the line if it did.
Thanks in advance
I would actually choose a totally different solution - updating valid dynamic IP's will be hell.
I would:
Create a new Project using the "Intranet Application" instead of using "Internet Application"
Host the application on your local office network
Set up VPN to your Office for your colleagues
Would this solution be possible for you?
I have an ASP.NET 2 application that sends email to specific users to notify them of certain events. The application uses the System.Net.Mail.SmtpClient class to construct the email and send it.
Whilst developing and testing the application I'd like to make sure we aren't sending emails to the production email addresses. I'd like to avoid branching in the application code (e.g. using compiler directives and build configurations) as this means not all code paths can be tested until we deploy the application to the production environment. Ideally I'd like to configure the application in development to use a development SMTP server host that takes all email and sends it to a specific address regardless of the address it was instructed to send to. Is this possible using Windows XP / IIS 5?
What other approaches could be taken in this scenario.
One aproach is get like a flag test or something, so that according to whats configured for example in web.config you send the email to test email assigned by you.
But in my opinion, this is a bit of hack, an alternative and more recommended solution would be set DeliveryMethod to SmtpDeliveryMethod.SpecifiedPickupDirectory in web.config and specify a directory for your messages to be saved, so instead of actually sending the email, you just create it and place it in a folder so you can check it out. This way you can have one web.config for testing and the other one for production that has DeliveryMethod set as Network with all production smtp settings.
I have an Asp.net application 3.5. I want to be able to allow multiple/ different clients to access the same application but using different URL's. I have already managed to configure the database to allow this.
So here's the main part.
I want to host my application in a domain say...
wwww.myapplication.com
then allow different client to access the same application using
1) www.clientOne.myapplication.com
2) www.clientTwo.myapplication.com
Also the client subdomains i.e(clientone.myapplication.com and clienttwo.myapplication.com)
should be autocreated by the client upon registration.
How can I achieve this..Your help will be greatly appreciated
A good example of how I want my application to work is
www.quickschools.com
I finally found out the solution that I wanted, so I thought I would share with you my finding. It turns out I needed to create a web application from another running Asp.net web application (From C# Code)
This tutorial by Robbe Morris was really helpful if you need to get started on this.
Another article you might want to check out is this one.
To have different url's using the same application, i would use "301 redirect" subdomains. I'm not really sure how to have a webapp create these subdomains.
I think the way to do this is to make the website the default website on the server i.e. configure so all requests to the servers IP hit this website (unless the header matches another website that explicitly looks for it). You do this just by not specifying a header on the IIS settings (only an IP address and a port number) - you can only do this for one site per IP address/port combination on the server.
Then look at the request url in the website to determine which domain was requested.
This way there is no need to 'create' subdomains... but you do need to reject all request to a domain that you don't want to recognize.
If you can't do this then you would need to adjust the IIS metabase from the application - not impossible - but a very risky and probably a bad idea.
The common case is that you'll have to configure a new virtual site for each of your new tenants during account provisioning. See Creating a New Virtual Server on how to achieve this programatically. Some though argue (with convincing arguments...) that spinning up an appdomain for each tenant is a waste of resources and one should use routing in the application that inspect the HOST header, see Multi-tenant ASP.NET MVC – Introduction.
Configuring IIS/ASP to respond to your tenant sub-dmains is the easy part. The real problem will be to configure DNS for your tenants, and that depends on your DNS solution.
Best practice says to keep my web app and database on separate machines, but when doing that it seems I can't get a clear explanation on how best to make this connection. Whil windows auth is the recommended authentication, I don't see how to make a trusted connection . Must I use impersonation to have my application connect to a db server?
Are most people simply using SQL authentication in this case?
Both machines are on a virtual cloud network.
If both computers are in the same domain, I'd use Windows Authentication for the SQL connection. To set it up:
Create a domain account to use for the app.
Give the id the absolute minimum priveleges necessary to host the site on the web server. For example, it must have read access to the web site itself, write access only to folders updated by the web site, etc.
Change IIS so that the domain account is used to run the app. In IIS6 & IIS7, you do this through the application pool. In IIS5, you have to change the settings in the machine.config or in the web.config for the ProcessModel.
All calls to the database will be done through this domain account; you won't have to setup impersonation. In fact, if you are using SQL authentication today, the only change you need to make is to the database connection string; no code changes are needed.
I have a Web Service (ASMX) with a few Web methods on our production Web server. On a separate internal Web server (which isn't publicly exposed) I have another Web site that will use the ASMX's public web methods. What are some of the best ways to secure the Web service such that only the internal Web server can access the Web Services running on the publicly exposed Web server?
One of the easiest ways is to pass credentials in the soap header of the message. So each call passes along the info needed to determine if the user is authorized. WSE makes some of that easier but one of the most succinct descriptions of this process can be found in Rocky Lhotka's book on Business Objects. I get a lot of books to review by publishers and this one had the best explanation
Assuming you don't have the option of using WCF, I'd advocate using WSE 3 (Web Service Enhancements). You can get the toolkit / SDK thingummy at MS's site
To limit the access to only internal machines (as I think your question asked), I'd set up a separate web site in IIS and set it to only respond to the internal IP address of your server.
I would set a firewall rule to restrict access to a whitelist of IP addresses.
Use IIS's directory security IP address restrictions, and limit access to just that internal web server IP address.
If you can't do that then, and you can't setup a username/password on the directory, then use WSE and add a username/password into the service, or look at certificates if you want some fun grin
Maybe I did not understand correctly, but why expose the web methods publicly at all if they're only going to be consumed by the internal server?
A simple HTTP module will work. Just hardcode (or from config) the allowed IP/host and reject all others.
If it is only the internal server that will be accessing the asmx files? You could set them up in IIS under a separate web site or virtual directory, then place some IP restrictions on the site. In properties, go under Directory Security, then "IP Address and Domain Name Restrictions."
Also, for passwords, WSE 3 is the new go-to, but I did find a simple method in a book from Apress called "Pro ASP.NET 2.0 in C# 2005" Chapter 34. (Note, the newer version of this book omits this chapter.) The section is custom Ticket-based authentication.
In this moment what comes to my mind is IP filtering on IIS. Fast to apply, should work in your scenario.
TLS with client certs. See Wikipedia entry to get started.
Be aware that there are ways around whitelisting IPs. Don't get me wrong, it's a great idea, and you should definetly do it, but if your budget/resources allow it, you can expand your threat model.