SitecorePatched The post is related to the image resize vulnerability fix introduced in Sitecore 7.5. To read more about the Sitecore fix go to the Release notes page and search for “Media request protection”. While I was holding off for a number of months on the publication of the post as it puts the attack vector in plainer sight that I would like it to be (while the community figured out how to work with Media Resizing in a neat way) – but recently I’ve seen voices raised considering turning the Media Request protection off which I hope you will not be doing after reading this post. The post will also tell you how to enable such security on your older versions of Sitecore.

So here’s the story…. At some point in Cognifide we have performed a research around Sitecore security and one of my colleagues (Marek)  found out that you could easily kill any Sitecore instance by performing an image resize attack on it. While the CMS did some rudimentary checks and limited the values of height and width you could still perform an attack by harvesting the images from the site and perform multiple parallel & iterative size increase or just plain use the scale parameter to achieve any image size. A result of such attack would be a a denial of service due to 100% CPU & memory usage and would potentially allow for filling the server drive by creating the endless number of scaling calls.

Marek was even kind enough to provide a proof of concept code that confirmed the hypothesis by performing attack on a few of our internal servers. The program would load the home page; parse to find images linked from it and perform resizing of the images in a number threads.

Psst… Mike made me add the image – supposedly without it I’m not as cool as Stephen!

Following the discovery I’ve attempted to remedy the problem and as a consequence came up with the solution which I have recently put on GitHub – ImageGuard which signs the rendered media links that use any of the resizing/scaling capabilities and filters all request that try to resize/scale, allowing the sizing only when the hash matches and provided it to Sitecore.

This solution is nowhere as complete as the one that was later provided by Sitecore – starting from version 7.5 – still I think it’s still worth making it public to allows for older versions of Sitecore to be guarded against this type of attacks. Read the rest of this article »

Sitecore PowerShell Extensions 3.0 Modules

brown_cardboard_box_light_800_clr_4510

A large problem with Sitecore PowerShell Extensions up to version 3.0 was the lack of proper separation of solutions provided on top of it from the core of the module. The problem is that all integrations look for scripts in the main Script Library but they look for them solely in their single libraries. The specification outlined in this blog aims at solving this issue. Read the rest of this article »

One thing I always wanted to add to the Cognifide PowerShell Console for Sitecore but never had the chance to investigate properly, was GUI and user interaction. For example in a regular PowerShell console when an irreversible action needs to be taken or one that user needs to be notified about – a question is asked:

image

Unfortunately due to the stateless and non-persistent nature of HTTP connections this is not easily achievable in Sitecore Sheer environment especially since in our case a PowerShell session usually lives in a separate thread within a Sitecore Job.

I knew this had to be achievable as Sitecore allows for rich interaction with user e.g. during a package installation process but I could not find any documentation regarding this subject, and my Sitecore gurus’ posts were pretty discouraging in that regard:

But heck(!) Somehow the package Installer manages to show those pesky Overwrite/Merge/Skip dialogs, right?

image

Not discouraged by the early discoveries, I’ve dusted my trusty copy of Reflector and dived inside the installer code. Following are the findings of my investigations and sample solutions for using them with your Jobs.

Read the rest of this article »

Posted in .Net Framework, ASP.NET, Code Samples, PowerShell, Sitecore, Software Development, Solution, Web applications
1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5.00 out of 5)
Loading...
| 1 Comment »

PowerShell Scripted datasources in Sitecore (Part 1)

sitecore-powershell-yin-yangReading some time ago the Item Buckets documentation I discovered something really cool called code data sources. We delivered something similar in our internal libraries and it proved super useful ever since. I’ve also recently read a nice article by Ronald Nieuwenhuis on NewGuid about their approach to the subject.

So what a PowerShell and Sitecore nut does when he sees stuff like that? Obviously delivers a scripted data source!

Why do that?

Just to prove that both Sitecore and PowerShell are infinitely malleable and mixable, is good enough for me, but that’s not really the reason someone other than me would be interested in it.

  • Delivering complex functionality based on multiple criteria. e.g. your field may need to provide different set of items to choose from based on:
    • user name or role (in simplest case this can be done using right management, but maybe not always possible in a more elaborate scenario)
    • current day or month?
    • In a multisite/multimarket scenario you may want to show different items for each site
    • based on engagement analytics parameters of the page
    • based on where in the tree an item exist (some of it can be done with use of a “query:”)
    • anything you might want to build the code data source for…

Something that would be beyond the reach of a regular Sitecore query and potentially something that you would really need to deliver code source for. But maybe you’re not in a position to deploy that on your environment?

Read the rest of this article »

Sitecore PowerShell Console in Visual Studio

A while ago Jakob suggested that putting the Sitecore PowerShell Console in Visual Studio might not be a bad idea. He even provided me with the boilerplate code that served as a stub for the module (Thanks a million Jakob!).

So after some struggling on my part the new module is now on the Sitecore Marketplace. There is really not much to write about. If you like PowerShell and Sitecore Rocks you will find it pretty neat. Otherwise I’m afraid those are not the droids you are looking for Uśmiech

Basically what it does is: it allows you to enjoy PowerShell automation while still skipping the web interface (that effectively is why you’re using rocks, right?).

Pre-Requisites are:

Installation is fairly straightforward. Once you download the zip file – unpack it somewhere on your drive and run the install.bat within it. Once you restart your Visual Studio you’ll be able to do the following:

OpenRocksConsole 

Which should result in the following outcome:

RocksConsoleOpened

Feel free to contact me or post your questions as a comment below.

Your own PowerShell commandlets

swiss-chocThere is a lot of new stuff in the imminent 2.0 release of the PowerShell Console for Sitecore. Some of it is fairly obvious like the improved console window, some of it not so much. The aim of the console has always be to enable Sitecore developers to extend the CMS in new exciting ways. For this to happen it had to become a mini-platform on its own. So far you could use it to add scripts to ribbons and menus, write scripted tasks and execute scripts just by launching them from a URL call.

That’s extending Sitecore with PowerShell but what about PowerShell itself?

One of the coolest features introduced in 2.0 is the ability to write your own commandlets. Sure you could always use PowerShell to do it and write commandlets in script. But then the caveat was that you had to attach such commandlets to your own scripts (or put them in the initial script that would have to execute prior to the console). Now I’m talking about writing the real commandlets, just like those that come with the PowerShell console itself. Starting from 2.0 the console does not default to only attach commandlets that come with it, but can also scan other assemblies to attach your commandlets. To add your own all you have to do is well.. write them but then… all you have to do is to use the standard Sitecore include mechanism to enable the console to find them.

Including my own commandlets into Sitecore PowerShell Console

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <powershell>
      <commandlets>
	<add type="*, Cognifide.PowerShell" name="Cognifide_PowerShell_Commandlets" />
      </commandlets>
    </powershell>
  </sitecore>
</configuration>

Where the type parameter is just a regular Sitecore type reference with a slight twist – you can use wildcards in it. So with the above example, the console will scan the Cognifide.PowerShell assembly and allow you to use all the commandlet classes that are tagged appropriately.

How to write a commandlet?

Read the rest of this article »

Posted in .Net Framework, ASP.NET, C#, PowerShell, Sitecore, Software, Software Development, Solution, Web applications
1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 3.00 out of 5)
Loading...
| 6 Comments »

State of PowerShell for Sitecore for April 2012

While I’m updating it on a separate page I thought for the purpose of having a record and further tracking – it would be interesting to capture the state of the PowerShell knowledge in the Sitecore community here as well.

Image Courtesy: Steven Tieulie

How do I get the PowerShell Console for Sitecore?

Read the rest of this article »

Sitecore PowerShell Console cheat sheet – Part 2

Most of this post is also based on the Microsoft’s Windows PowerShell Quick Reference however despite the sharing scripting runtimes the nature of the both shells differ considerably as described in the previous post: Sitecore PowerShell Console cheat sheet – Part 1. In all cases where it made sense I’ve converted the samples to establish them in Sitecore scenarios.

How to Write Conditional Statements

To write an If statement use code similar to this:

$page = Get-item .;
$changedBy = $page."__Updated by";

if ($changedBy -eq "")
  { "Unspecified author - a system page?" }
elseif ($changedBy -eq $me)
  { "The page has been last edited by me!" }
else
  { "The page has been last edited by "+ $changedBy }

Instead of writing a series of If statements you can use a Switch statement, which is equivalent to VBScript’s Select Case statement:

$page = Get-Item .;
switch ($page.Language) {
    "en" {"This version is in English"}
    "pl" {"This version is in Polish"}
    "tlh-KX" {"This version is in Klingon?!"}
    default {"No idea what this language is!"}
  }

How to Write For and For Each Loops

Read the rest of this article »

Continuous deployment in Sitecore with PowerShell

A few days back a budy from our Sitecore team has alerted me to this interesting question on StackOverflow which asks for automation of content promotion from one Sitecore instance to another. He suggested – and rightly so – that the PowerShell Console could be used in that scenario. While this was always possible by simply writing it as a PowerShell code the latest version of the console added a few commandlets making building packages much easier.

The easiest approach is to build the package visually in the package designer, save it and then simply use the console to read it and generate the installation zip like:

get-package "powershell console.xml" `
  | Export-Package -FileName "PowerShell Console.zip" -Zip

That’s fine in most cases but if you have some more complex scenarios or want to generate some custom packages – you might want to generate packages directly in PowerShell.

To Create a Package you simply use:

$package = new-package "Test Package";

Now that you have that package you might want to add some files and items to it.

Let’s add for example our item templates by querying the master database and creating a dynamic item source:

$TemplatesSource = get-childitem "master:/templates/Cognifide" `
  | New-ItemSource "Cognifide Templates";

And subsequently add it to our new package:

$package.Sources.Add($TemplatesSource);

While that by itself is fairly useful, the really cool part is that you have a full flexibility of PowerShell at your disposal when you create a source with static items. Let’s say you want to add all items of template “Article Template” that reside anywhere under your “home” node … now that would require quite a bit of clicking in the Package Designer, but is trivial with the PowerShell Console:

$ArticlesSource = get-childitem master:/content/home/about-us/* -recurse `
  | where-object { $_.TemplateName -match "ArticleTemplate" } `
  | New-ExplicitItemSource "Cognifide Articles";

$package.Sources.Add($ArticlesSource);

You can specify any automation or filter you can think of to your Get-ChildItem, and you really don’t have to skimp on the number of data sources – after all you can re-generate your package at any time!

Similarly you can do this to the files on disk. Let’s say – you want to add all .aspx, .ascx and .ashx files, just to make sure your deployment features all the latest code and for the sake of this example let’s assume your UI elements are located in the Layouts folder under your web application:

$LayoutsPath = $AppPath+"layouts\*"
$Layouts = get-childitem $LayoutsPath -include "*.as?x" -recurse -force `
  | New-ExplicitFileSource "My Layouts";
$package.Sources.Add($Layouts);

Easy enough… now let’s add everything that is within the bin folder as a dynamic file source:

$BinFolder = New-FileSource "Bin Folder" -Root "/bin"
$package.Sources.Add($BinFolder);

That is it really… you may want to specify your package metadata which you would do like:

$package.Metadata.Author = "Auto generated " + `
  [DateTime]::Now.ToShortDateString();
$package.Metadata.Comment = "Isn't it cool?!";
$package.Metadata.Publisher = "Cognifide";

and then save it for later opening in package designer:

$package | Export-Package -FileName "test package.xml"

alternatively you can open such package as specified earlier

get-package "test package.xml"

if you ever wanted to add more sources to it or export as a zip file to be imported with the assets in your target environment:

$package | Export-Package -FileName "test package.zip" -Zip

… now on your target machine you need to upload your package to the Data\Packages folder. But then to install it all it takes is:

Import-Package "test package.zip"

Obviously all of it can be hooked to ribbon, context items, or be scheduled… but I get ahead of myself…

So how does it all relate to continuous deployment?

All of this can be completely automated, all you need to do is create a Script item as described in one of my previous posts and call the PowerShell execution URL referencing your script from your CruiseControl server or whichever continuous integration product you use in a fashion similar to:

http://myhost/Console/Layouts/PowerShellResults.aspx?scriptId={1680E211-BD28-49BE-82FB-DA7232814C62}&scriptDb=web

You need to deal with the fact that you are most probably not logged in with your continuous delivery environment – in this case probably best approach is to use the web database or the script item my turn out to be unavailable to you and the script will not execute.

Now in your source environment your script will create the package and upload it to an FTP server (there is plenty of ways to do this from PowerShell… you can find a couple of samples on Stack Overflow) and subsequently call a second part of the script on the target server.

On the Target server – a complementary script will be executed in the similar fashion – by the originating server and if you don’t have direct access to the file on the FTP server you’ve just uploaded – you can download it and import the package.

Now if you integrate the script with a ribbon in Content Editor on the source server (like described in the previous post) you can have a one-click-deployment solution on your dev machine, but then the REALLY cool part would be to integrate it with the context menu (as described in this post) and be able to push parts of the site to production with a single click! Not to mention your nightlies can really be nightlies if you do it using the scheduled tasks integration.

Extending Sitecore ribbon with PowerShell scripts

Sitecore is built from the grounds up with extendibility in mind. Be that plugging into any place in its internal pipelines or any aspect of its User eXperience, therefore when I’ve managed to extend it’s context menu, I expected to have no problems whatsoever doing the same to its ribbon. Mind you I was right…

Using the PowerShell Console Module it took me less than 10 minutes total to add a nice piece of functionality that I thought was missing – Publish items I have modified.

ContextScriptsRibbon

Similarly to extending context menu – first I’ve created the script I wanted to execute that will take the current item and it’s sub-items and publish them by adding a new script item using the /sitecore/templates/Cognifide/PowerShell Script template in the core database. I’ve put it in the same place I store all my my scripts – in the /sitecore/content/Applications/PowerShell Console/Scripts branch but feel free to store them anywhere in the tree.

  • Filled in the Script body part with my script.
  • I decided I want to see the publishing results as I want to verify if the items I expected got published.

ContextScriptRibbonBody

Now the UI integration bits…

Since I wanted it nicely integrated with the publish button – I’ve created a Publish My Items item of template /sitecore/templates/System/Menus/Menu item within the /sitecore/content/Applications/Content Editor/Menues/Publish/ branch in the core database, set it’s icon and reference the script item in the Message field using the following pattern:

item:executescript(id=$Target,script={0937769B-998D-4580-B9FE-730C4CDABECD},scriptDb=core)

where the script guid is the ID of your script and the scriptDb is the database the script is located in.

ContextScriptsRibbonBinding

That’s it really. You can download the solution but I would strongly recommend you try the manual approach – it’s really exciting to see the puzzles click in.

The solution requires the Sitecore PowerShell Console from Cognifide, available for free from Sitecore Shared Source site.