Forums (Obsolete)

Member

matthew.newby-crl - 2/6/2014 10:33:40 AM

Content Staging page templates result in lost .Parent relationships

Lost a few hairs yesterday trying to fix this problem... I'd made some changes to an HTML Envelope web part on several page templates and a transformation on our dev server -- replacing H1 tags with H2's in the HTML before and after to improve our SEO placement (can't have too many H1's on a page, you know). After reviewing the changes with our web content manager, I used the content staging module to push just those changed templates and the transformation to our QA/Production environment (after also making sure that none of the other object changes in the Content Staging list had anything to do with those templates or the transformation).

A day later, he noticed that on our production website a number of pages were missing a background banner image and the H1 text that overlays that image. Like any good programmer, I started digging around in the code to make sure that I'd not inadvertently changed anything related to the banner. As near as I've been able to determine, the code is identical on both dev and QA/Prod. Hairs were lost here...

What I did notice is that the two things that were broken in the banner web part both made reference to the .Parent document. The banner web part is a Document Attachments web part, and it looks for an attached image to use as the background graphic, calls the transformation to build the needed markup to display it, and sets the banner text to the document name. BUT, if there is no attachment, the No Data Behavior, No Record Found Text is used instead:

<section id="banner" style="background-image:url(/getattachment/{%CurrentDocument.Parent.Attachments.FirstItem.AttachmentGUID%}
        </h1>
      </div>
    </section>
  </section>
</section>

After using the Content Staging module to push the templates to QA/Prod, the values returned by these macros was NULL, resulting in the background-image:url(/getattachment/); and the H1 text being empty.

Later afternoon troubleshooting with the web content manager on a web conference, I added some static text to the H1 after the macro, and clicked the OK button on the Banner web part configuration popup. Reloading the page in another browser (Internet Explorer, not logged in to Kentico), I saw that, surprisingly, the background image was now being loaded, the parent document name appeared, and then the expected static text I just added showed up. I went back into the Banner config popup and removed my static text, and hit OK. Reloading in the other browser resulted in a correctly functioning page including the expected graphic and text. Navigating in IE to any other page that uses that template showed that all of them were now functioning properly.

The workaround fix for all the other broken pages was to edit the templates on QA/Prod, open the Banner web part config popup, then click OK, WITHOUT MAKING ANY CHANGES. Loading any of the pages that use that template in IE showed that the banner graphic and banner H1 text were now properly resolving the .Parent. value and showing the expected image and text.

I have no idea why the .Parent relationship appears to break after using Content Staging to move the page template, nor why changing nothing and clicking OK in the web part config restores the relationship. This appears to be a bug, unless I missed something very important about content staging and page templates.

-matt

Kentico Support

kentico_jurajo - 2/7/2014 1:53:54 AM

RE:Content Staging page templates result in lost .Parent relationships

Hello,

I am sorry for the inconveniences. This is most probably due to the macro security - on source the macro is signed with some hash but, after staging it it does not match the target environment hash. Have you checked the Event log yet? If there are any macro errors regarding macro security, please see this macro security documentation where you will also learn how to ensure the same hash signature across environments.

Best regards,
Juraj Ondrus

Member

matthew.newby-crl - 2/7/2014 2:58:53 PM

RE:Content Staging page templates result in lost .Parent relationships

Thanks Juraj. I AM seeing errors in the event log (although the errors from a couple days ago are no longer listed). One recent example is

Security check of the expression 'CurrentDocument.Parent.Attachments.FirstItem.AttachmentGUID|(user)administrator|(hash)(and there was a long hash here)' didn't pass. The expression was signed by user 'administrator'. Remove the signature and re-save the expression by a user with proper permissions.

Checking the Admin > System > Macros, it looks like it is using the database connection string, which would be different between our dev and production environments. Also, there is no CMSHashStringSalt web.config key set at the moment.

So, what's the recommended best practice for signing the macros when using content staging? Is there a non-disruptive way to either get all the current macros signed without having to find all of them and re-save them? What's the risk of using unsigned macros?


Kentico Support	kentico_jurajo - 2/9/2014 4:05:35 AM RE:Content Staging page templates result in lost .Parent relationships Hello, One option is not to sign the macros or, second option is as described in the documentation us the hash salt different than the connection string. The salt will be tyhe same on both environments and then the hash signature will match. Best regards, Juraj Ondrus

Member

matthew.newby-crl - 2/10/2014 3:26:35 PM

RE:Content Staging page templates result in lost .Parent relationships

Juraj,

Thanks for the response, but I'm not sure I've asked my questions well enough to figure out what to do next. I understand from reading the documentation you referenced in your first reply that there's a couple options for configuring macro signing. However, I'm still unclear about the risks and impact of the options.

The documentation says that by adding a hash function and signing the macro expression, security is improved. It describes the default mechanism of using the database connection string as the salt, and explains how to disable the signatures using the "@" sign, and how to modify the web.config appSettings section to use a static salt.

What I was trying to figure out, given that we're currently configured using two different salts on our dev and qa/production environments, is first, what kind of risks are we facing if we used unsigned macros? Related to that question, is it possible to configure something on the whole site so that it defaults to unsigned macros, or do they need to be disabled explicitly by editing every on of them and changing the closing tag to use the "@" symbol?

Second, if there are significant security risks associated with using unsigned macros, it looks like the recommendation from the documentation is to use a static salt and update the web.config on both environments. Unfortunately, the BEST time to do this is before starting any development -- a time period that is well over and done! The doc says "Changing the salt causes all current hash values to become invalid." Looking at the section of the docs that talks about repairing invalid signatures, it's not clear to me what procedure I would follow if I were changing from using the default connection string to a static salt, and what the anticipated outage would be between invalidating the existing signatures and carrying out the resigning effort. Can you give me some indication as to how long the anticipated outage might be?

Kentico Support

kentico_jurajo - 2/11/2014 3:02:26 AM

RE:Content Staging page templates result in lost .Parent relationships

Hello,

1. The rsiks are that a user that has no appropriate permissions can view or access data or use the macro to grant herself with higher pemrissions, etc. The macros have to be changed manually to use "@" not to be signed so it is clear and the macro author knows what is she/he doing. Otherwise it would be considered as a security hole in Kentico.

2. You do not need to update web.config file. Also, that's why there is the interface in Site Manager so you can re-sign the macros after the developent or at any time if something in your topology changes. You need to fill in the old salt (connection string by default) and add new salt (and this new salt have to be the same on both environments) and then re-sign all the macros using the button - on both environments. After this, all the macros on both instances will have the same signatures.

Best regards,
Juraj Ondrus