After my previous post outlining my custom Feature Receiver used to update any section of a web.config file, I had some follow up email conversations with Mike about his post and us possibly collaborating on a combined CodePlex solution. Well, that hasn’t happened yet. However, during that discussion, we talked a bit about security. Mike referred me to a post by a colleague of his inspired by this very topic. The gist of the discussion and post is that modifying the web.config with a Feature Receiver really only makes sense, from a security perspective, when the Feature is scoped at the web level. I agree, so I needed to make a small change to my custom FeatureReceiver.
The change I needed to make was simply to make sure that it did not update the web.config if the Feature was not deployed at the web scope. This was a pretty simple change, but I took the opportunity to do a bit more research on the topic to see what others had done. The best nugget I pulled out of this research time was a change in the way I was applying the updates. Turns out there is an issue applying an update using
Using that method, the changes don’t get applied to the entire farm. Since we’re in a farm environment, I would’ve run into that at some point. The solution is to use this instead:
Continue to the end of this post for some more reading on the topic. For now, here is the code update I made:
Like I said, this is going to look a lot like the code in my previous post. The first change is in the first few lines of the try block. I assume the parent of the Feature is a Web App. If it gets a reference, great. If it doesn’t, it logs an error and doesn’t do anything else. It would be nice if there were a way to actually stop the Feature from being deployed, but that can’t be done in a Feature Receiver (it happens after the Feature is activated.)
The second change is at the end of that code snippet, and is to account for the Farm update issue I mentioned earlier.
That’s it. Like I said, not much has changed, but I wanted to put out an update in case others are using this approach.
For further reading, here are some references:
(That last one is useful because he lists the types of features that are allowed at each scope. Can save you some time so you don’t implement this method to deploy something that can’t be deployed at the WebApplication level.)