Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Steve Smith 75 posts 158 karma points
    Dec 20, 2013 @ 11:11
    Steve Smith
    0

    Database corruption on saving changes to a document type

    Hi guys,

    We have recently updated our Umbraco 4.7 installation to 4.8 (with a plan to upgrade further when we have time to test everything properly).  Microsoft SQL Server 2012 "standard" backend database.

    Everything was fine for a while, but this week we've been having some serious problems when saving changes to document types.

    Basically, after saving a change to a document type, when accessing a node in the Umbraco back-office that uses the document type, a server 500 error is thrown - "Multiple controls with the same ID 'prop_' were found. FindControl requires that controls have unique IDs"

    When we look back at the "settings" tab and view the document type, a load of the properties have been blanked.  They still all exist, but have no name, alias, description or data type.  Same thing happens to the tab properties.  The tabs still exist, but have no name.

    When I look in the database, in the table "cmsTab" for the document type node Id, the "text" field for each row is blank.

    Likewise, the table "cmsPropertyType" has blank values for "alias", "name" and "description".  And the values for "mandatory" and "dataTypeId" have been reset to some kind of default.

    No ASP.NET errors in the system event log during the "save" operation, and nothing out of the ordinary logged in the umbracoLog table either.  The front-end of the system works fine (presumably because its relying on the XML cache of the site, and not the database copy).

    Our "fix" on the two occasions its happened this week is to manually reinstate the wiped field values by comparing the records from the "cmsPropertyType" and "cmsTab" tables from a known good backup.

    We're running Umbraco as a large multisite CMS, so each document type save is a proper "need... more... coffee..." moment (even more than normal!).

    Just wondered if anyone had come across this before?  Of course, making a backup of the database and the C:\inetpub folder, and performing the same operation on a developer's machine works fine (as is always the way).

    Thanks,

    Steve.

  • Steve Smith 75 posts 158 karma points
    Dec 20, 2013 @ 12:30
    Steve Smith
    0

    To reply to my own topic as a warning for others (and in case anyone ever Googles this issue)...

    We think the problem is down to a Cisco Intrusion Prevention System (IPS) that we have running between the client and server.

    Found some entries in the IPS log at around the time the document type changes were saved.

    It appears the IPS doesn't like the contents of the POST data when saving the changes to the document type in the Umbraco back-office, and is partially stripping or truncating the request before sending to the Umbraco server.  Thus, Umbraco is not receiving the full set of form data from the client, which is leading to a load of the field values being set to an empty string.

    Waiting for our IT team to turn it off so we can test properly.  However, if I log in to the server using Remote Desktop and perform the same "save" operation using http://localhost/umbraco/, it works just fine.

    This of course is not helping change my opinion (honed over some 20 years in IT) that well meaning security appliances/software can do more damage than they are supposed to prevent.  But, if I'm right, it seems that Umbraco doesn't check server-side whether certain critical fields are empty before updating the database, which seems a bit of an oversight?

Please Sign in or register to post replies

Write your reply to:

Draft