Database: Oracle, MS SQL Server, MySQL, Access;

Languages: C#, Visual C/C++, Java, Visual Basic, Perl, ASP, PHP;

Web-development: HTML, JavaScript (including JQuery, JQuery UI), CSS;

Microsoft .NET Framework (including good practical knowledge of ASP.NET);

Mobile development for iPhone and Android, using PhoneGap / HTML5 / jQuery Mobile;

Content Management Systems, such as Drupal, Joomla, as well as lower-level frameworks such as ASP.NET MVC;

Miscellaneous Technologies: XML, XSLT, COM+, ActiveX, SOAP, REST.

Two months ago we received an email from the site’s hosting provider, stating that the site “has been hacked and used to run illegal software on the server”, for which reason they’ve completely shutdown both the site and its control panel, until we tell them that we’ve made all the necessary preparations to correct the problem — which meant removing the vulnerability that was exploited, as well as taking steps to reduce the chance of any other vulnerabilities.

I need to note that on the site itself, prior to it being shutdown, there was nothing to indicate any problems. All looked fine.

The way the hack was done was by using an insecure request processing in one of the modules used with the Joomla (a Content Management System) on the site. The module, developed by a third party, was not checking one of the possible request types, which could come from any visitor’s browser, for possibility of malicious code. This meant, that some commands could be executed on the server of the hosting by calling the site in question with the following link:

SITE_ADDRESS/index.html?option=MODULE_NAME&controller=../../../../../../../proc/self/environ%00 HTTP/1.1″ 200 3573 “-” “Mozilla/5.0 mimot

mimot”

This request should work in the following way — the controller code for the specified module is called, and it is passed the parameters in the call, which get processed by “good” code afterwards. What happened in reality is that the parameters in the request link were not “sanitized” by the code of the module (this is a standard safety procedure, which was left out by the creator of the module by mistake), thus allowing the parameters to contain some “bad” code, which was executed as part of the controller call, before the “good” code was invoked.

The passed parameter contained “bad” code which executed the following actions:

• Moved many folders up the file structure from where the actual site is located (so further code was executed in the environment that is not even available to the site administrator accessing the site with standard means — FTP or control panel). It is possible that the number of levels that the code needed to be places is standard for the hosting server the site is located on, and that folder could contain service utilities used by many other sites.
• Got a remote file “FILE_NAME.jpg” and stored it locally. We checked what this file was — if you looked at it using a text editor, you’d see that it was not an image, in spite of the extension, instead it is a collection of executable scripts that allow remotely performing any actions on the server where this file is installed. Powerful badness.
• Renamed the file to “count.php” (supposedly choosing a file that executes often), thus turning a fake image into an executable file.
• Listed all the files in that directory with a lot of additional information (perhaps to use for further attacks).

Upon receiving the notification from the hosting provider, with the above link information, we took the following vital steps:

• Don’t panic. It doesn’t help anyway, but also we concluded that the site is now closed (until we remove the vulnerability), and the malicious code was already removed by the hosting provider, so no more harm can be done.
• Study the threat. We never saw anything like this before, so it took some time to understand what the above link was doing and how, and what needed to be done to prevent it.
• Look for other survivors. We searched the forums of Joomla webmasters to see if there were other victims of the same vulnerability — and it did turn out that this vulnerability became apparent just a few days before it was exploited on our site, and the very helpful Joomla community did already provide ways to close the door of the risky module.
• Restore the site from the backup. This is also a very important step, since we didn’t know what other actions the hacker may have done on the site after gaining access to it. It is possible that the database and administrator user passwords were stolen, that additional dangerous code was installed, etc. Thankfully, our trusty provider has an automatic daily backup procedure (which keeps backups of the site, both the files and the database, for 7 days), thus the site was restored to the state before the hacker attack. It was unfortunate that the content placed on the site after this point was lost, but it was an acceptable cost of knowing that the site is now completely clean of any changes by the intruder.
• Remove the vulnerability. Applying the knowledge of the nature of the threat, and the advice from the forum folk, we edited the module code to include sanitizing of parameters processed by the controller code.
• Change the passwords. Restoring the site from backup ensured that it is “clean”, yet the hacker could have obtained various passwords (most notably, the database password, since any CMS needs to store it separately to enable its own code to access the database). So we changed all the important passwords.

After performing these steps, we notified the hosting provider, and the site was enabled again.

One of the things that we also learnt while investigating the threat is that the module used on the site has not been updated by its author for over a year, so it looked risky to continue using it as opposed to something that has more active support and community. For this reason we looked for an alternative that would satisfy the site’s goals and, thankfully, were able to rather quickly find a replacement. Open source community is a great crowd to interact with, and if there is a problem that many people need to deal with, somebody out there is most likely working on a good solution for that problem.

The lessons we learnt from this accident:

• Nobody is invincible. Even if you write all of your code — you may still make mistakes. But if you depend on software or modules created by somebody else – the chances are even higher. That doesn’t mean that we should panic (because — we shouldn’t), instead, we need to do everything possible that the risks are minimized, and that there is a plan in place for dealing with problems before they arise.
• Backups. Without these, we’d have a lot more work to do. So, when creating a site, always think about periodic backups, whether they are done by the hosting provider, or whether the site backups itself on a cron job. These are vital, and we were truly thankful we had one.
• Keep the software up to date. Since any site usually depends on several third-party modules, and vulnerabilities may often be discovered and fixed in those modules, it is important to make sure that you are always running the latest and most secure version of the software. I love how Drupal CMS deals with it — there is an “Update” module which periodically checks for any third party module updates, and notifies the site administration if an update is needed. For Joomla such a centralized solution does not seem to exist, so we put in place periodical reminders to check whether there are any updates to the components, modules and plugins used on the sites that we maintain.
• Minimize the risks. This is a general statement, and needs to be applied to the specific site configuration. At least one can say that it is best not to use any third party addons unless really necessary, and, if needed, then you should choose modules that are well maintained, have an active community around them, and solve as many tasks of your site as possible – so that you don’t need to rely on too many of them. There are also many security checklists which describe how file access etc should be configured — these should be followed by definition, at least the official one: http://docs.joomla.org/Security_Checklist_7.
• Follow the vulnerability news. For Joomla, there is a security news feed for the vulnerabilities found in the Joomla core itself, and a feed with constant updates on discovered vulnerabilities in Joomla extensions. We are now subscribed to both of those feeds, watching them closely for news about any features that are used on our sites.

And, above all, don’t panic! We hope this information will help you avoid such accidents in the future and, if they do happen, to be able to solve them with least damage to you and your customers.

You can find the description of preliminary design stages in the previous articles of the series, one on studying the peers, and one on interviewing the key site users.

The Goals

A static teaser site was published during the development process, to make sure the basic information (contacts etc) is already available, and so that the search engines start indexing the site in advance.

Based on key user interviews and investigation of other similar sites, the following goals were defined and agreed with the decision-makers, ordered in descending priority:

1. Inform the visitors about the life of the Regional Union, including both the past events and the future event announcements.
2. Offer resources for educating people serving in the main directions of church ministry. Some resources need to have their access limited to specific user groups.
3. Provide reference information about the Regional Union — about its departments, churches, contact information.
4. Allow the site visitors to communicate with each other and with the Regional Union office — in order to receive answers to their questions, as well as to establish contacts.
5. To explain what the Bible talks about important issues of the contemporary life, in order to bring the Good News of Salvation to those people who don’t know God, and also to equip those who would like to share the Good News.

The Audience

The next step in addition to the above goals is to define the potential audience of the site, as follows (with their potential goals of the site):

1. Church members (check the news, find out about future events, find a church by geography, study provided education materials, find out more about the Regional Union, ask a question, participate in a discussion of a topic or of an article on the site).
2. Ministers (goals the same as above, with addition of possibility to contact some other pastors or the Union leadership, find pastoral or ministry resources with restricted access, leave a request to add new resources.
3. Content editors (in addition to above tasks, they may need to add and edit new content, moderate the discussions, respond to questions).
4. Guests (the tasks are different from the above groups – find out more about what the Baptists believe in, find an answer to an interesting topic, ask their own question to start a discussion, contact somebody who can help find what they need).

The Structure

One of the “mockups” (also called “wireframes” sometimes) created in Balsamiq tool in order to visualize how the various page types may look. You’ll notice that some things changed in the process, generally in order to simplify the site.

Based on the above goals and audience, several possible user scenarios were created (too wordy to post here, but I can share examples if you’d like – just ask in the comments below the article). This led to defining content types which the site would hold, and, finally, designing the site structure and navigation for the site users to complete their goals by easily finding the needed content types and functions in the site. These are the resulting site sections and their purpose:

1. Home - introduction to what the site is about (for first-time visitors), as well dashboard-type summary of all the site activity (for both new and returning vistors),
2. News - articles on past events and announcements of the future events, as well as an easy access to news archive.
3. Library - educational materials, by ministry type.
4. Forum - for discussions, including a restricted-access sub-forum.
5. About Us – to contain information about the Baptists, the Regional Union, and its departments. Additional content type in this section is listing of churches (which turned out very easy to do using Drupal’s user-filtered Views).

Additional “helper” screens were also included in secondary navigation – Contact, Help, Sitemap pages, and the Search form. For each of the above page types the required functionality was listed, to make sure that the site goals and audience information above is not lost in the increasing number of details describing the future site. For example, it was noted that users should be allowed to comment any material on the site, and, for their convenience, they should be able to subscribe to receive site, material and discussion updates via e-mail.

After all of this was reviewed, discussed with the decision makers and (finally!) confirmed, it was time to continue with the site development – which will be described in the final article of the series, to come soon, so stay tuned (subscribing via RSS, for example). Also, I would be happy to hear feedback on this approach – whether you are using similar process, or perhaps something different – you can leave your comments below the article (no registration required).

You can find the other articles of the series here:

• Engineering a web-site, step 1: Study of the peers
• Engineering a web-site, step 2: Interviewing the key users
  
• Engineering a web-site, step 3: Goals, users, structure (this article)

In step 1 of “Engineering a web-site” series, “Study of the Peers”, I described why I think that designing and implementing a site is essentially an engineering task, and how I looked at other sites with a similar task, and what lessons I learnt from this process.

The main risk to handle was that of me creating a site that nobody will ever want to populate (since that’s not what they needed), and thus it will attract no visitors and will generally serve no purpose. So my next logical step was to talk to those people who could potentially become contributors to the site.

As you may remember, the formal Informational Architecture (IA) process consists of these steps:

1. Site’s goals.
2. User experience.
3. Site content.
4. Site structure.
5. Visual design.

We are still on step 1 of that process, defining the goals, yet that’s not something to be discouraged about – I’d rather spend extra time on getting the goals right, instead of making a site that serves no definite purpose.

Lots of talking

First of all, of course, I talked with the head of the regional union of baptist churches, and got his opinion on what the site should be and whom it should be for. I was sure to ask who the main decision-maker would be if any issues arise, and was pleased to hear that it would be him – committees can be good for some things, but not for making responsible decisions.

From him I also got a list of all the departments of the union (corresponding to various ministries – Sunday school, church planting, evangelism to prisons, and so on), which had the phone numbers for the person responsible for each of the departments. My reasoning was that these people are in the midst of the events in the union, so they can be a very good source of information and news – it would be great if I could find out their preferences and create a site that would make them excited.

Additional bonus is that these people also represent a part of the future site’s audience, as they could use it to find out what it happening in other departments and other churches, and they could use the site to communicate with their friends and co-workers in the church world. So I could hit two birds with one stone, hopefully not hurting them too much as a result.

Thus began the public part of my work, as before that not too many people knew that a site is being cooked, and now I would suddenly create all these expectations in people. Again, that’s a good thing, having more responsibility actually helps getting things done, and having them done properly.

In all, I spent some lengthy conversations with 12 people, on the phone or in person. The main questions I asked are in the following categories:

• How much do you use Internet? What are the main tasks you perform on the web? (to get a general feeling of how knowledgeable a person is, and also to get a better insight into what kind of audience the site may serve)
• What web-sites do you like the most, and why? What do you not like in web-sites? (again, to get a feel on what may and may not work for these people in both content and visuals).
• What are the goals of your department?
• How could a web-site help to achieve these goals? (a very broad question, I know, but one that I could hear some good ideas from)
• What kinds of content and how often do you think you or your department could contribute to the site?
• Do you look forward to your organization having a site, and would you be willing to be actively participating in its life? (if you read the first step of “Engineering a web-site” series, then you know that my main concern was that I need to gather a team – this question has that specific purpose)

When all is said and heard

The summary of each such conversation was recorded in a single “Key Users Interview Notes” document, which is very interesting to re-read after the site is finished Each department wishes to have a brief page about them, with possibility to post news or announcements. Everyone wanted a “library” of sorts, though not too many people were sure they’d be able to suggest any actual materials for it. An important idea was stated that it would be good to have a catalog of all the region’s churches on the site. Leader of music ministry wanted to be able to post sheet music, which expanded the idea of “library” to more of a free-form resource center, rather than just a list of articles. One person insisted that a “restricted” part of the site is needed. There would also be photo-heavy reports from different events.

Some people also couldn’t say much, since they don’t use computers or Internet too often, and that was also important to hear – the site would need to be as simple and clear to such people as possible, since they are also an important part of the baptist union, and we wouldn’t want to leave them behind.

Lessons learned

My written conclusion at the end of all the interview sessions:

Everyone mainly thinks of making a site of the members of the union itself, providing materials for church members only, and some even think that it is needed only for the ministers – deacons and pastors.

Most popular requests for the site (sorted by subjective importance, taking into account how often a feature was mentioned by different people):

• News, reports, with photographs.
• Educational materials for teachers, pastors, preachers (articles, books, series of lessons, with inclusion of files in PDF and other formats, multimedia). Important to have materials categorized by ministry type, for easier searching.
• Announcements of future events.
• Information about departments and churches, with contact details and addresses. This information should always be available, and never slide down into the archives, as regular news do.
• The site needs a section for fellowship – be it a “forum”, a “chat”, an FAQ page – I need to review available tools and decide which one suits the site’s goals the best.

It is also possible to create a section of the site which would be directed at the visitors who are not a part of the union’s churches – yet it is hard to decide how it should be done, as nobody shows much interest in developing it. Perhaps there could be a series of “About Us” articles for such guests, or a separate FAQ page for important questions – this needs to be decided.

My impressions? Very happy, since some of the things these people were saying sounded like a complete definition of functionality, exactly what I was looking for. I needed to define the site’s goals, and these interviews gave me a very good idea. On the other hand, it was very hard to tell who would actually be participating in the site, but several people did show genuine interest, so I was hopeful.

You can find the other articles of the series here:

• Engineering a web-site, step 1: Study of the peers
• Engineering a web-site, step 2: Interviewing the key users (this article)
• Engineering a web-site, step 3: Goals, users, structure

Coming next: Finalizing the site’s goals, getting a confirmation.

Stay tuned (RSS is so handy for that), and I would love to hear what you think in the comments to this article.

Engineering? Isn’t it a kind of art instead?

Yes and no. It is an art, and many art forms together — when talking of design, we usually think of visual art. Yet that should come as the last step in the process. Before that, it is an art of communicating with the customer, to find out what they want. Art of asking the right questions — and art of finding good answers. Art of organizing information, of removing the unneeded extras, of convincing the customer that “everything” is not a good idea. That is art, yet to keep it all properly structured, to ensure that no key factor is missed, I’d like to call it an engineering art.

(you can see the final design of the front page of the site to the right.) In order to produce a logical and usable output, I looked for a step-by-step process usually called “Information Architecture”. The rough outline of the process was built on many articles and thoughts in general, in particular I enjoyed the Information Architecture tutorial posted by the kind people at webmonkey.com. It describes the following IA steps:

1. Site’s goals.
2. User experience.
3. Site content.
4. Site structure.
5. Visual design (see, it is the last step in the process!)

I didn’t follow them strictly, though, but they gave me a good framework to think about and to make some of the key decisions.

Where I was closest to the “Art” idea was in the main project direction, since it was formulated as “we need a site”. I was left with the task of defining what purpose (other than simply “being”) the site will serve, for what audience, with what content and in what form and structure.

Overcoming the peer pressure, or “How does everyone else do it?”

To avoid starting with a blank canvas, I’ve performed analysis of other similar Ukrainian sites — searching for regional unions, communities, churches etc. When working on a business or commercial site, this step would be named “researching the competition”, yet in the case of this project these other sites can’t and shouldn’t be treated as competing, since their service directed to a single common goal.

Surprising result — out of 24 regions (“oblast”) of Ukraine, only one regional union site was announced — and even that site was down. Bad luck (actually, something to think about), but I found some regional youth sites, church sites, plus carefully studied the main site of the Evangelical Christian Baptists of Ukraine. All these gave me an idea of what content, features and structure are popular in the community, which I listed in a document and presented to the person who gave me the whole “make a site” task.

The content types I found in my investigation:

• About us page (describing the church or organization, contact info, addresses etc).
• Description of activities, ministries, reoccurring events in the church / community.
• A news feed (including future event announcements).
• Articles, sermons, books — in textual, audio and video formats, both created by the church / organization and, *ahem*, “borrowed”.
• Rich musical sections — note sheets, chords, lyrics, recordings of church choirs and bands, as well as famous Christian singers (yes, Ukrainians love music, no doubt).
• Photograph galleries.
• Discussion boards (aka Forums).

This all looks fairly common, so I knew that I would need to allow for the same kinds of content one way or the other, yet how to structure them so that the visitors can find it if and when needed — that’s an important decision, but I could make it only after deciding on the site’s goals and audience. Until then, having an inventory of the possibilities was enough, and was a good start.

Learning on others’ experience

I also made one important observation. The fact that most of these sites seemed inactive and poorly maintained was both alarming and thought-provoking. At the end of this research phase I presented the following written conclusion:

The absence of working regional sites probably means that there is no defined need – either by the leadership or by the people tasked with distributing information in their region. The fact that many of the church sites are rarely updated most likely means that they were created by techy enthusiasts, as they’d do it for themselves, without thinking through how these sites could serve their visitors. This also impacted the visual styling and content editorial quality of these sites.

The only fully active site is the all-Ukrainian one, and it seems to be led by a single maintainer, who continuously “bugs” people to provide news updates and other types of content (N.B. I found this out from a couple of “journalists” who are providing information for the site; since then the site’s design and management were changed, and I don’t yet know how it is operated at the moment).

Therefore, a site can exist and be active on the following conditions:

• Clarity on the site’s purpose and goals, whom does the site exist for (majority of the information on the studied sites is only interesting to the person who’s maintaining the site), and this purpose has to be carried in both the site’s structure and its content.
• There should be a team of people who understand the site’s goals and its audience, and who play an active role in populating the site with content that corresponds to the goals and is interesting to the audience.

Even though this conclusion may be stating the obvious, having relevant research materials to base it on really helped me in further discussions with the key people in the organization, to explain to them why we need a goal, and to paint them a vivid picture of the risks a site encounters if not everyone is on board on what it is for and whom it is for.

Knowing the risks was also important in continuing with the site’s design and implementation.

Research is a good idea

I have to say that the results of this investigation were not all negative. I found good decisions and solutions on those sites, and I wrote down the structure, the content types of each site, how the contact information was presented, what kinds of discussions or interactions were happening on. That was a good foundation to develop on, so I am thankful to their creators and maintainers, especially knowing that their job may be a difficult one when they don’t have a team of people to share and support their ideas and the desire to improve their on-line ministry.

You can find the other articles of the series here:

• Engineering a web-site, step 1: Study of the peers (this article)
• Engineering a web-site, step 2: Interviewing the key users
• Engineering a web-site, step 3: Goals, users, structure

Coming next: Determining the key decision-makers, conducting interviews, summary of the feedback.

Stay tuned (RSS is so handy for that), and I would love to hear what you think in the comments to this article.

What are these difficulties, you might ask. Organizing a QA process requires:

• a lot of preparation, as we work on the test-cases during or right after the design and specification phase,
• intensive back and forth communication, both between the QA engineers as they coordinate testing assignments, especially on interdependent tasks, and communication with the development team on the implementation detail, especially when issues are found,
• and there’s reacting to feedback that is sometimes delayed, since the development team may already be working on other tasks, and may not respond to an issue immediately, — thus making a face to face meeting not always possible,
• plus lots of reporting and the management keeping a close eye on those reports — to determine when a task is ready to be shipped, or when adjustments to priorities or assignments may be in order.

All of this boils down to efficient communication between several team members, so let me show you an example how we solve some of these issues.

A real-life QA scenario

Let’s assume that we plan a new version 3.3.0.0 of our software product. There are two tasks planned for delivery in this release:

• Task #1001 New report screen in Forecasting Area.
• Task #1002 Implement widgets in Home Page.

To initiate the process, I create a new Google Wave: “Version 3.3.0.0”, as you can see on the screen below (apologies for having to compress some of the screenshots to get all the data in):

In order to facilitate interaction, I add 2 people to this wave — Vadim (a QA Engineer) and Alexander (the developer assigned to this task). They can edit this wave and view any changes which were done to it by other people.

Then I create the following directory structure in Google Docs, to contain both the specifications and the test-cases for the planned tasks:

I upload the following documents into Google Docs:

• Specifications for Task #1 and Task #2 to the “Tasks” folder.
• Test Cases templates (these are still empty, for the QA guys to populate) to the “Test Cases” folder.

You can see the specifications here:

And the test-case templates are here:

These documents are shared with the specific people involved in the development and testing process, so that they can view and edit them as necessary:

When this is all done, I update the “Version 3.3.0.0” wave to add links to the corresponding documents, now the wave serves as the main control panel for accessing the needed data and asking questions or providing feedback and status updates:

The actual assignment of the test cases to QA team members can be as easy as leaving a comment, or one could edit the task list and write the person name near the task they are assigned to:

And get confirmations from each of the guys:

When test cases are complete I can review and approve them straight from Google Wave, and then I can delete the unnecessary comments or data from the wave. The ready test cases may look like this:

When version 3.3.0.0 is implemented and ready to be tested, Alexander from the development team updates the wave, and may also let know the location of the latest source or installation files to test:

This is when we, the QA team, may start the actual testing process:

As testing progresses, which we can also discuss in the wave (though we are more likely to discuss progress in person), I can quickly check every test case and see the overall results:

If every single test case has PASSed status, I can report that version 3.3.0.0 is successfully tested, the tasks are completed, and the wave may now be archived:

As you can see, this approach is practical and simple. If the team consists of many members, one may need more ways to filter and display data from the reports, yet for smaller teams this solution works well. Please let us know in the comments if you use something similar, or perhaps you can suggest an alternative approach.

Just remember: no tool or process will ever replace common sense and responsibility.

Let’s say we have a DLL written in C, called “native.dll”, and we need to call method getSomeList() of the DLL, which returns a list of items to populate a drop-down control in WPF. In order to implement this, we need to take the following key steps:

1. Create new context for invoking the DLL method.
2. Invoke the DLL method in the newly created context.
3. Access the control’s properties and methods in the context that the control was created in.

The sample code below demonstrates this in more detail.

///<summary>

///Interaction logic for Window1.xaml

///</summary>

public partial class Window1 : Window

{

   // Contextfor accessing controls

   private System.Threading.SynchronizationContext originalContext = null;

   //We need to import the function

   [DllImport("native.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.StdCall)]

   static public extern byte getSomeList(int no, StringBuilder name);

   // Constructor

   public Window1()

   {

      InitializeComponent();

      // Obtain the context in which the controls were created

      originalContext = System.Threading.SynchronizationContext.Current;

   }

   // Populate the list on window load event

   private void Window_Loaded(object sender, RoutedEventArgs e)

   {

      try

      {

         // Create context for invocation of getSomeList() from native.dll

         System.Threading.SynchronizationContext sc = new System.Threading.SynchronizationContext();

         object cr = null;

         // In this new context, call the list method

         sc.Post(ActualGetSomeList, cr);

      }

      catch (System.Exception ex)

      {

      }

   }

   // Method for receiving the list and accessing the control

   private void ActualGetSomeList(object obj)

   {

      try

      {

         // Receive the list

         string[] listItems = GetSomeList();

         // Call method, which populates the drop-down cbSomeList

         // in the context in which it was created

         originalContext.Post(SetListItems, listItems);

      }

      catch (System.Exception ex)

      {

      }

   }

   // Method for populating the drop-down

   private void SetListItems(object obj)

   {

      try

      {

         //populate the drop-down cbSomeList

         string[] listItems = (string[])obj;

         if (listItems!= null && listItems.Length > 0)

         {

            cbSomeList.ItemsSource = listItems;

         }

      }

      catch (System.Exception ex)

      {

      }

   }

   // Method receives a list from native.dll

   publicstring[] GetSomeList()

   {

      try

      {

         byte nErrorCode = 0;

         List<string> list = new List<string>(10);

         for (int i = 1; i < 10; i++)

         {

            StringBuilder sbName = new StringBuilder(100);

            nErrorCode = getSomeList(i, sbName);

            if (nErrorCode == 0)

            {

               string tmp_ = sbName.ToString();

               if (!string.IsNullOrEmpty(tmp_))

               {

                  list.Add(tmp_);

               }

            }

            else throw;

         }

         return list.ToArray();

      }

      catch (Exception e)

      {

      }

   }

The ever-changing Microsoft

On some reading, we find that Microsoft have changed the game rules in Service Pack 2 for Windows Server 2003. The functionality that supports automatic collection of process’ dump files for COM+ was changed, and, as it turned out, there was also a change in the logic that completes processes exceeding a certain period of run time, as described in Knowledge Base article 910904: A change in the functionality of COM+ in Windows Server 2003 to support automatic collection of a process dump file and process termination.

All would be good if it led to gathering data and raised a corresponding warning, yet, unfortunately, a process that runs for an “unusually high time” is terminated, while the event type is a mere “Warning”:

Event Type: Warning

Event Source: COM+

Event Category: (117)

Event ID: 1001

Date: dd.mm.yyyy

Time: HH:MM:SS

User: N/A

Computer:

Description: The average call duration has exceeded 10 minutes. If this is not the expected behavior, please see article 910904 in the Microsoft Knowledge Base at http://support.microsoft.com for details on how to use the COM+ AutoDump feature to automatically generate dump files and/or terminate the process if the problem occurs again.

Server Application ID: {………..}

Server Application Instance ID: {………..}

Server Application Name: I-Plan

Of course, we know which processes in our application take longer than 10 minutes, and we know what causes it, so we didn’t need such a “gift” from Microsoft.

Solution

The problem can be solved in one of the two following ways, depending on the requirements of your application and server:

1. Global change to COM+ behavior

Make the following changes in your system registry (please be careful when modifying the registry, it is not a joke that one can easily break Windows by mis-doing something here):

In the registry path: HKEY_LOCAL_MACHINESOFTWAREMicrosoftCOM3AutoDump (if AutoDump does not exists — please create that branch), add the following keys and their corresponding values (type DWORD):

• AverageCallThreshold, set to 3000, — this is maximum allowed duration of process execution, in seconds. If it is exceeded, a warning is raised.
• Terminate, set to 0, — this flag defines behavior on exceeding maximum execution time, 0 means that the process will continue, 1 means that the process will be terminated.
• DumpType, set to 2, — this flag defines the dump creation behavior, 0 means that a full dump file will be generated, 1 that a minidump file will be generated, 2 defines that no dump file is to be generated.

2. Change behavior of a specific COM+ application

In order to change the behavior of a specific COM+ application, instead of making a global server-wide change, create the above keys and values in the following registry path: HKEY_CLASSES_ROOTAppId{<YourAppID>}AutoDump{<YourCLSID>}.

It is preferable not to set the AverageCallThreshold to be too high, and simply allow the process to continue. At least this way you will be able to collect enough statistics about potential problem spots, and when they appear — to, possibly, try to solve high execution times if they are not needed for your application’s business logic.

PS If it is so easy for Microsoft to change the logic in their server OSes, wouldn’t it be even easier to stop “supporting” the old bugs from Internet Explorer 6 in the more recent IE versions? Just asking.

Background

This came as a surprise, since our customer, Trading Science Ltd, is using security certificates (Microsoft Authenticode content signing certificates from Thawte) to ensure the validity of the ActiveX controls. What should happen is when the user installs the control for the first time, it is shown as signed (one less thing to worry about for the user), and a question is asked if they would like to trust that publisher to silently install controls in the future.

The ActiveX signing step is part of our automatic build process, so that every control version that we release is signed, without any reliance on manual actions. And that worked great, yet recent tests and closer inspection revealed that the publisher name, as stated above, is no longer available.

Symptoms

This is visible especially well in the Add-on manager of Internet Explorer 8, instead of a correct publisher name one can see message “Control name is not available”:

Project resources description

The description of the issue, as it seems to happen so often, is far from being actually descriptive. Yet the solution turned out to be simple — after some search, research and experiments, we noticed that the resource description file (it has the .RC extension) of the ActiveX control project has empty properties. In particular, the property “CompanyName” was not populated:

Put the publisher name into that field:

And the result is…

Publisher displayed, but “not verified”

This is better — in the IE8 add-on manager we can now see the publisher name displayed correctly. Almost:

What do we do with the unpleasant “Not verified” label in front of our publisher name?

Full solution

Again, the problem description is not clear — there is no need to actually “verify” the publisher name, everything is already verified and signed by an authoritative provider. What needs to be done is to make sure that not only the .cab file (cabinet containing the control) needs to be signed with the certificate, yet also the controls that it contains — all the .DLL and .OCX files. We used the same certificate that we already had to sign everything, and received the long awaited result:

Please let us know if you have any additional questions of comments.

We saw this issue while creating a standalone ATP/CTP* Client (you can read more about this product on the site of our partner, techwire UK, in the feature titled “Web-based Ordering”) for I-Plan, a supply-chain management application. This client (and the corresponding server-side enhancement) is an application that allows to demonstrates the ATP/CTP logic, usually “hidden” within the main I-Plan core, and also it provides possibility for external systems to send ATP/CTP requests to I-Plan using a web-service API.

Oracle 9 Connection Issue

The problem occured when connecting to Oracle database server version 9, using standard DB client from Microsoft in .Net Framework, System.Data.OracleClient, the following error would return:

System.Data.OracleClient requires Oracle client software version 8.1.7 or greater

So, it would seem that at least Oracle version of 8.1.7 was needed, or greater — while we were using 9! Additional difficulty in investigating and solving the problem was that it didn’t occur on all the servers that we tried it on. So it took us some time to find a solution, therefore we hope it may be useful to you someday.

Solution

To solve it, we had to perform the steps below on every server where the issue occurs — so there is no generic programmatic solution to this, unfortunately. It is required to give the authenticated user a privilege to the Oracle Home in Oracle 9.2 Client software, as follows:

1. Log on to Windows as a user with Administrator privileges.
2. Launch Windows Explorer from the Start Menu and and navigate to the ORACLE_HOME folder. This is typically the “Ora92″ folder under the “Oracle” folder (i.e. D:OracleOra92).
3. Right-click on the ORACLE_HOME folder and choose the “Properties” option from the drop down list. A “Properties” window should appear.
4. Click on the “Security” tab of the “Properties” window.
5. Click on “Authenticated Users” item in the “Name” list (on Windows XP the “Name” list is called “Group or user names”).
6. Uncheck the “Read and Execute” box in the “Permissions” list under the “Allow” column (on Windows XP the “Permissions” list is called “Permissions for Authenticated Users”).
7. Re-check the “Read and Execute” box under the “Allow” column (this is the box you just unchecked).
8. Click the “Advanced” button and in the “Permission Entries” list make sure you see the “Authenticated Users” listed there with:
   

   Permission = Read & Execute
   Apply To = This folder, subfolders and files

   If this is NOT the case, edit that line and make sure the “Apply onto” drop-down box is set to “This folder, subfolders and files”. This should already be set properly but it is important that you verify this.

9. Click the “OK” button until you close out all of the security properties windows. The cursor may present the hour glass for a few seconds as it applies the permissions you just changed to all subfolders and files.
10. Reboot your computer to assure that these changes have taken effect.

And then it works!

As you can see the solution is far from obvious, especially if one looks at the original error message. Thankfully, there is a helpful development community around Oracle and .Net, so we found the above on one of the forums. Please feel free to post your feedback or questions in the comment form below.

* — ATP/CTP stands for “Available To Promise” and “Capacity To Promise”, two modes for ordering items, the former checking whether the item is available in inventory (across several warehouses, in our case), the latter checking if there is available production capacity to manufacture the required quantity of the material in time.