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.
Related
I have published an orchestration as a WCF web service using WCF_WSHttp bindings. I think we about the SSL certificate working. It will be open to the internet, thus anyone who knows the URL could call it and pass data; so we want to add user/pass authentication. We simply one the one client/vendor to have the ability to call this webservice, no one else.
I've been reading everywhere, and cannot find any specific steps.
I think I want something like Scenario #4 here: https://seroter.wordpress.com/biztalk-and-wcf-part-ii-security-patterns/, but I cannot see how he got the "Client Credentials" box to pop-up in BT-2010.
Best I can tell is I have to:
1) In BizTalk Admin Console - set Security Mode to TransportWithMessageCredential.
2) From here: https://msdn.microsoft.com/en-us/library/bb226482.aspx, I'm a little confused about the difference between Windows and Username. An outside vendor is calling our webservice, so they are not on our domain. Do I need to set up a service account? Or can I just make up a username and insert it here somewhere?
3) Do I have to make corresponding changes to the WCF web.config that was created by the BT-2010 "WCF Servcie Publishing Wizard"
It seems like your're looking for just Basic authentication on the transport layer? All you then have to do is to create an AD user or a local user on the BizTalk machine and set the Transport client credential type to Basic.
If I pass in some Ids from an Asp.net application to SSRS server to render reports - how do I make sure that Ids are not read/modified by the end user?
One way I guess is to use ReportViewer control in Asp.net app and have SSL implemented, but is that foolproof? or are their better/alternate ways to implement security in such an app.
Three levels you could do for security purposes:
Change the default port on the SSRS server to something other than 80. EG: Change it to 81 and then someone needs to connect via: http:// (servername):81/ReportServer. Using a different port makes traffic not on the common internet port of 80 may be a good way to hide usage. This would also require that on the server hosting this port that you open this port up under Windows Firewall settings for use with this application.
Use the HTTPS with a certificate to determine that connection is valid between a host and target.
Set up only a single user on the SSRS Site aside from a local admin. Give that user read only rights. Set up your application to authenticate to the ReportViewer via remote mode but HARD CODE this value into your method, do not put in an app or web config. This way someone would have to have access to source code to be able to view user, they would not be able to get into the SSRS site to even see the user if they were not a local admin on the server hosting SSRS.
Those are my ideas anyways. Most of the time people have problems with SSRS being too secure to just get in versus yours you want more security. I hope some of this helps as I know that this method I cannot say is 100% foolproof(nothing is IMHO) but it now has added a level of complexity in adding a different port as well as a dedicated user with minimal permission only viewable by one other account but can be hardcoded in front end applications.
You can also add your security to your report level. Use User!UserID to capture who is logging into your report. and check that with a dataset you create from the application database that manages the access rights to the reports. This way, you can filter the data from showing for wrong users.
Note: Please consider this as another layer to your system security and Do not rely only on this. There are ways that a power user can go around this.
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.
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've built an ASP.NET application that's using Forms Authentication. In our hosting account control panel, I set up an automated task that requests a web page once per week. When the page loads, a number of emails are sent out.
I'd just like to know if there's any way to determine in the code-behind if the request is coming from the local machine (as with Windows authentication). Using a separate web.config file in the page sub-directory with Windows authentication mode doesn't work.
The application will work fine either way. I'm requiring that a specific Guid value be present in the query string, so it's very unlikely that the task will be executed by mistake. I'd just like to learn something new while I'm working on this, and I'd like to see if I can add this little bit of extra verification.
Thanks very much for any advice.
Request.IsLocal
The IsLocal property returns true if
the IP address of the request
originator is 127.0.0.1 or if the IP
address of the request is the same as
the server's IP address.
Request.Url.IsLoopback