– ad set up in DFP
– targetingcriteria set using various key-value pairs

– server side calls marketing service provider web service to get data about customer, passing in user ID from cookie
– server side component written to dynamically generate javascript code; this javascript code contains the dynamic key-value pairs – this js code is along the lines of ad.doubleclick.net/gender=m
– when javascript code runs, it injects html via document.write(‘…the ad content…’)
– html displays the actual ad

HTTP slow vulnerability is a DDos attack based on the way HTTP works. HTTP will only process requests once it has received a full header. If an attacker sends this in chunks over a large period of time then they can open multiple connections and time out the web server, blocking genuine requests going through. There are 2 main changes advised:

Set a minimum HTTP header length in IIS – this will ensure that HTTP header requests have to be AT LEAST x bytes
Reduce the maximum server request length (in seconds)

Of course, adjusting these values to extremes could result in legitimate requests being rejected, so there is no magic value to set. The only way to figure this out for sure is to measure, over a period of time, what are acceptable boundaries and set accordingly.

public class HttpParamActionAttribute : ActionNameSelectorAttribute {
    public override bool IsValidName(ControllerContext controllerContext, string actionName, MethodInfo methodInfo) {
        if (actionName.Equals(methodInfo.Name, StringComparison.InvariantCultureIgnoreCase))
            return true;

        if (!actionName.Equals("Action", StringComparison.InvariantCultureIgnoreCase))
            return false;

        var request = controllerContext.RequestContext.HttpContext.Request;
        return request[methodInfo.Name] != null;
    }
}

How to use it? Just have a form similar to this:

<% using (Html.BeginForm("Action", "Post")) { %>
  


<% } %>

and controller with two methods

public class PostController : Controller {
    [HttpParamAction]
    [AcceptVerbs(HttpVerbs.Post)]
    public ActionResult SaveDraft(…) {
        //…
    }

    [HttpParamAction]
    [AcceptVerbs(HttpVerbs.Post)]
    public ActionResult Publish(…) {
        //…
    }
}

The following code snippet will work with MVC Mailer:

<smtp from="some-email@gmail.com" deliveryMethod="SpecifiedPickupDirectory">
          <network host="localhost" />
          <specifiedPickupDirectory pickupDirectoryLocation="c:\temp\"/>
  </smtp>

The reason for this is that the mySQL driver does not support the MultipleActiveResultSets property that SQL Server supports, therefore when iterating over a list containing lazy loaded items the driver attempts to open another connection to fetch the new items and falls over.

Sadly the only way around this is to eager fetch the items, like so:

1

var q = from t in dc.testresults.Include("entity").Include("scheduledtest") where t.ScheduledTestID == scheduledTestID select t;

The error I kept getting was “TypeError: myClass is not a constructor”.

Thanks to the JetBrains community, a fix was at hand quickly.

I had to make sure that a test-config.jstd config file was in the root, which loads the prototype.js framework.

The content of this file is:

load:
- prototype.js
- src/myGlobal.js
- src/myClass.js

test:
- test/Test.js

UPDATE: Further work on this revealed a bit of a UI snafu which cost me a bit of time. The above configuration is set on each configuration – NOTE: FOR EVERY UNIT TEST CREATED THERE IS A NEW CONFIGURATION CREATED.

So sometimes it would run the above configuration, other times it would run the default (where it would be looking for prototype.js in the same folder as the class files).

Be careful when running your unit tests and always double check where the config file is pointing to.

On looking at some of the tutorials I found this article.

Have copied some of it here for future reference.

Automate, automate, automate!
By moving from a logging based debugging routine to unit testing we have made sure that our experiments are repeatable and self-checking. Doing so takes a lot of manual labour off our backs, but there are still ways to improve. Running the HTML file containing the tests in a browser is fairly painless, but as you might have noticed, today’s web developers can’t simply test in a single browser and call it a day. Depending on your environment, you may have to test the 2+ most recent versions of 5+ browsers on 3+ platforms. Suddenly, running that one HTML file is a bit of work.

As mentioned, the test case object above is written for JsTestDriver, a JavaScript testing framework and test runner from Google. What sets JsTestDriver apart from the pack is the way it runs tests. Rather than the standard HTML file to load sources and tests, JsTestDriver runs a server that can help you run tests on multiple browsers all at once. The best way to understand how this works is to see it in action.

Assume that the jQuery plugin lives in src/difference_in_words.jquery.js and the test case lives in test/difference_in_words_test.js. In order to run this test we add a configuration file, jsTestDriver.conf in our project’s root directory. It contains the following:

server: http://localhost:4224

load:
– src/*.js
– test/*.js
Now download the latest JsTestDriver jar file. You will need Java installed to use it. Then issue the following command in a shell (if you are on Windows, cmd.exe will do):

java -jar JsTestDriver-1.2.2.jar –port 4224
You have now started a JsTestDriver server on your machine. The next step is to point a browser to http://localhost:4224/capture which will turn the browser into an idle test running slave. Do this with all the browsers you have available. Then open a new shell, cd into the project directory and issue:

java -jar JsTestDriver-1.2.2.jar –tests all
After a short while you should see some output indicating that JsTestDriver ran two tests in all available browsers, and show you whether they passed or not. Congratulations, you have just automated testing on multiple browsers! If your machine is reachable from other devices on the network, you can also use this server to test other platforms (OS X, Windows, Linux), your iPhone, Android phone and other mobile devices. And you can verify them all with a single shell command. That is pretty exciting!

JsTestDriver is not your only choice for test automation. If you don’t like its assertion framework, it can also run tests written using QUnit, YUI Test and Jasmine. Additionally, Yahoo has YETI, a similar tool built specifically for YUI Test, and Nicholas Zakas recently released YUI Test Standalone, which includes a similar runner based on Selenium Web Driver.

Continuous integration
When practicing TDD, we require tight feedback. Feedback comes from our tests, which means that tests need to run effortlessly and fast. JsTestDriver already makes it both easy and fast to run tests, but as always there are limitations. The limitations come in the form of multiple browsers. While JsTestDriver can easily run tests on as many browsers as you want, doing so is inconvenient for the TDD workflow for a couple of reasons:

Having test reports from more than one browser at a time makes it harder to see what’s happening, and takes away from the momentum TDD is supposed to provide you with.
Some less capable browsers – which are usually highly important to test – are slow. And I mean slow. Slow ruins the TDD flow.
One solution to this problem is continuous integration. Continuous integration is the practice of automatically and frequently controlling the quality of your project. This could include tools such as JsLint, and it most definitely should include running tests.

A continuous integration (CI) server can make sure that the work of all developers combined work as intended and it can also be the one in charge of running tests in a wide selection of browsers. A “build” on a CI server is usually triggered by version control systems such as Git or Subversion, and will often offer to send emails to project members when it discovers problems.

I recently wrote a guide to setting up the Hudson CI server for JsTestDriver. Using Hudson and JsTestDriver, it’s easy to build a workflow that is time-efficient and promotes quality.

Personally, I use TDD for basically anything I do, and usually I run tests locally against Firefox, as it is the browser I find to have the best error messages and stack traces. Every time I finish a feature, often a small one, I push it to the code repository. At this point, Hudson checks out the change I just committed and runs all the unit tests on a wide range of browsers. If anything fails, I get an email explaining what happened. Additionally, I can visit the Hudson server anytime to view graphs of the project’s builds, see console output for individual builds and so on.

Use TempData when you want to display a notification to a user. When MVC accesses the TempData dictionary, it will delete the corresponding key-value pair. In order to determine if a TempData value has been set, don’t check for null (!) but use ContainsKey.

You can’t pass TempData values to an HTML Helper, e.g. within a @Html.ActionLink.

To get around this, use a standard a tag and the Url.Action helper, e.g.

@if (TempData.ContainsKey("LatestActionJobID"))
{
<div id="divLatestAction" class="info">
    <h1>
        <a href="@Url.Action("Index", "Job", new { id = @TempData["LatestActionJobID"] })">@TempData["LatestAction"]</a>
    </h1>
    <span class="close">X</span>
</div>
}

The architecture

Borrowing on ideas from this post, we want our architecture to resemble something like:

The problem

However achieving this is not as straightforward as it sounds. If we want to use the Entity Framework as our ORM, then we have to be aware of what happens when WCF tries to serialize/deserialize this to and from our application layer. The first sign of trouble was when I got this message:

System.Xml.XmlException: The maximum read depth (32) has been exceeded because XML data being read has more levels of nesting than is allowed by the quota. This quota may be increased by changing the MaxDepth property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 1, position 5230.
at System.Xml.XmlExceptionHelper.ThrowXmlException

The hack would have been to increase the read depth to a higher level, but that isn’t addressing the real problem, and of course there is no guarantee what might happen later.

The reason this exception is occurring in the first place is due to the entire object graph being deserialized by WCF. There is probably a cyclic navigation path between two objects (e.g. object A has reference to object B, and object B has reference to object A) and so the XML goes on for ever.

Easy fix? Detach the object before sending them back across the wire from the WCF service.

Okay, that will work and give you the top level entity, but what I found was that the children of this entity were all NULL. So that didn’t work for me.

POCO

Going back to the architecture above, what we want to do is work with Entity Objects in our DAL, but by the time we get to the service/app level we want to work with POCOs – Plain Old CLR Objects. Problem with this is that WCF cannot directly serialize or deserialize the POCO proxy type.

This is because the proxy types are dynamic types, and the serializer can only, as ever, work with known types. The above workaround, applying ProxyDataContractResolver, did NOT work for me, although that’s perhaps because of my slightly different approach.

Following the steps in the first article, I set up my Entity Data Model as normal, although this time I download the POCO Entity Generator so that I can then create POCO classes from my EDMX.

Move the .tt template into the Model project and change the source to point to the original EDMX in the Data project.

For those classes that need custom business logic, I then create partial classes to correspond with the relevant auto-generated POCO partial data class.

So, to recap, I now have an app layer which calls methods on my WCF service to return a list of POCO data objects. The WCF service in turn calls the data layer, which gets the data but puts this into POCO objects in the Model. The WCF service then returns these POCO Model objects, instead of the Entity Objects.

More problems

Everything should have worked…. but it didn’t.

I received a generic error message:

An error occurred while receiving the HTTP response to http://localhost/FtyDataService/MainService.svc. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.
The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.

Debugging the WCF service didn’t help at all – it would happily get to the end of the method and it was only on the return (serialization routines) that something was going wrong. But what? I’m sure those of you more adept at WCF than myself will know the answer straight away, but I had to debug the problem using the SvcTraceViewer tool.

SvcTraceViewer

The SvcTraceViewer is a great tool to debug inside WCF services. To use it, you need to:

• Set up Trace in the web/app.config
• Install .NET 4.0/Windows 7 SDK
• Run the service; this will generate diagnostic files in the root of the service solution, and open the tracelog.svclog in SvcTraceViewer (probably in C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin)

This will show each activity, and any exceptions will show up inside each activity in red. The inner exceptions are then displayed.

The exception is uncovered:

There was an error while trying to serialize parameter http://tempuri.org/:GetUserDataResult. The InnerException message was ‘Object graph for type ‘FtyModel.Team’ contains cycles and cannot be serialized if reference tracking is disabled.’. Please see InnerException for more details.

To eliminate this error, I had to add

[DataContract(IsReference = true)]

to the top of the .tt file, so that each POCO class had this attribute.

(reason why explained in this SO post)

The next run worked, but didn’t return any data. The obvious reason for this was that no property had [DataMember] marked around them. Once fixed, data was returned.

UPDATE: Marking the POCOs as DataContract, DataMember is unnecessary (and not even correct!). POCOs should be clean, unmarked classes.

The “cyclical references” error can only be sorted out by stopping WCF from getting in a bind (infinite references when it tries to serialize) by using an attribute – http://chabster.blogspot.com/2008/02/wcf-cyclic-references-support.html

However, IMPORTANT – this attribute is NOT respected when using the in-built WCF service client!

There are plenty of resources available for the Repository and Specification patterns, although each one seems to be slightly different. So keeping with tradition I’ll take you through my version!

I want two “types” of repository – a repository bound to a SQL Server datasource via EntityFramework and a repository bound to an in memory data set. This will allow us to quickly simulate the application by detaching from the underlying database. The workflow for the app has several ETL routines running, so actually testing the flow of the application will be difficult without being able to instantly put the application into a particular state.

For this I will be using Spring.NET a my IoC container, however this is beyond the scope of this article.

My base repository will expose methods FindOne and FindMany – these will take a ISpecification as input. The ISpecification classes contain the query logic. This keeps the query logic self contained, and also means they only need to be written ONCE across multiple repositories.

The base repository therefore looks like:

    public interface IRepository
    {
        void Add(T owner);
        IQueryable All { get; }
        void Delete(T owner);

        ///

        /// Finds entities based on provided criteria.
        /// 

        IList FindMany(ISpecification criteria);

        ///

        /// Finds one entity based on provided criteria.
        /// 

        T FindOne(ISpecification criteria);
    }

ISpecification:

    public interface ISpecification
    {
        Expression> IsSatisfied { get; }
    }

In Memory Repository:

    public abstract class IMRepository : IRepository where T : class
    {
        protected List all;

        public IMRepository()
        {
            all = new List();
        }

        public void Add(T owner)
        {
            all.Add(owner);
        }

        public IQueryable All
        {
            get
            {
                return all.AsQueryable();
            }
        }

        public void Delete(T owner)
        {
            all.Remove(owner);
        }

        public IList FindMany(ISpecification criteria)
        {
            var query = All.Where(criteria.IsSatisfied);
            return query.ToList();
        }

        public T FindOne(ISpecification criteria)
        {
            var query = All.Where(criteria.IsSatisfied);
            return query.FirstOrDefault();
        }
    }

Status Specification (query Order records):

    public class StatusSpecification: ISpecification
    {
        private int _statusId;

        public StatusSpecification(int statusId)
        {
            _statusId = statusId;
        }

        public Expression> IsSatisfied
        {
            get
            {
                return p => p.Status == "test";
            }
        }
    }

To use, our unit test looks like:

IUnitOfWork uw = new IMUnitOfWork();
var spec = new StatusSpecification(1);
var list = uw.Orders.FindMany(spec);

At the moment, this works really well, however time will tell if it can handle more complex real-world scenarios.