August 3rd, 2016 by Adam Najmanowicz | 33 Comments
I’ve received this nice comment on one of my earlier posts and I thought it might warrant a blog post since it is a nice little challenge and might be useful for more scripters in our community.
Hi Adam,
thanks for the pointers on PowerShell! There’s one in particular I’m hoping to get some help with, if that’s ok? I have created a Branch Template in Sitecore, and I want to deploy it under every item in the Content Tree that uses one particular page template (about 200 instances of deployment, in this case). For an added bit of fun, there will be several different language versions being deployed along the way, so I guess that prevents me doing a blanket rollout. Could you please recommend a script that is along the lines of “Add this Branch Template under this Item ID in the following named language codes”? I realise I would then be repeating that line 200 times with varying parent item ID and languages, but I can live with that if that’s the easiest way to do it.
Many thanks for your help!
Phil Neale
First let’s set up a bit of a folder structure for our PoC.
#Clean-up after previous run
Remove-Item master:\content\branch-test -ErrorAction SilentlyContinue -Recurse -Force
#Create a folder strcture for our tests
New-Item master:\content\ -Name "branch-test" -ItemType "Common/Folder"
foreach($i in 1..3){
#Create folders for items that we will serve as branch hosts
New-Item master:\content\branch-test -Name "folder $i" -ItemType "Common/Folder" | Out-Null
foreach($j in 1..3){
#Create items underneath which we will be creating our branches
New-Item "master:\content\branch-test\folder $i" -Name "branch-host $j" -ItemType "Sample/Sample Item" | Out-Null
}
}
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 »
In one of my previous posts I described how to create reports in Sitecore PowerShell Extensions (SPE for short) that allow you to leverage the joint power of Sitecore and PowerShell to deliver complete and elegant reports in little to no time. In this post I?ll tell you how to take this a step further and operationalize them into full blown Sitecore Desktop applications.
The secret sauce is in the actions you can place on the report, the additional parameters that I haven?t mentioned in the previous post, and the use of Sitecore rules engine with some rules that come with SPE.
For the purpose of this post I will limit the scripts to samples that are (mostly) in the vanilla SPE deployment.
Let?s begin with describing the actions and how you can configure them to appear in your reports.
What are report actions?
Actions are simply commands powered by scripts and with visibility dependent on certain conditions like the .Net class of the object that is displayed or perhaps other session settings.
You define an action as a script located in an SPE script library and appears in the Actions panel. In the simplest scenario the action would appear when the script library name matches the .Net class name of the items displayed. In the above scenario the actions are placed under /Platform/Internal/List View/Ribbon/Item/ where Platform is the module and Item is a script library. Let?s take a look at the script here /Platform/Internal/List View/Ribbon/Item/OpenRead the rest of this article »
Recently the Sitecore PowerShell Team has been reflecting on the progress of the Sitecore PowerShell Extensions (SPE) module. We appreciate all the feedback and contributions from the community. Without the many great people in the community, the module just wouldn’t be where it is today. The team is proud of the accomplishments for a module developed purely by the community with no formal Sitecore support.
The new year has revealed some exciting news out on the Marketplace for SPE.
Our community content reference page have been visited 9722 times over the past year with the number gradually growing to 1343 page views last month alone.
Since we’ve seen some interest from developers wanting to join the Sitecore PowerShell Extensions team, I thought it might be worth documenting how my development environment is put together to allow for easier on-boarding of new members (Yes, we’re hiring! No, we can’t pay you ;) ). Maybe you just want to compile it yourself to make sure we’re not up to no good, or just plain see inside and play with it…
First of all you need to have Sitecore installed somewhere (obviously). For the purpose of examples I’ll assume your instance is located at C:\inetpub\wwwroot\Sitecore8\ and has the 3 standard folders Data, Databases and Website in them as it normally has. For that very same reason I’ll also assume that your Sitecore PowerShell Extensions project folder is located at C:\Projects\SitecorePowerShell\
1) Seed your Sitecore instance
First step that I always perform when I setup a new environment is to seed the Sitecore instance with the items required which is best done by installing the latest release of PowerShell Extensions.
2) Set up Sitecore SPE folders to use the latest files you’re working on
Since we’re likely to modify the assets like JavaScript, styles or XML Controls I want those to be automatically synchronized with changes I do in C:\Projects\SitecorePowerShell\ for this purpose I set up junction points in my Sitecore instance folder to point at my repository folder. To do this I delete the folders that were created by the install package and perform the Junction creation. Assuming the folders as they were specified before you can write a short batch file that would look like this: Read the rest of this article »
February 27th, 2015 by Adam Najmanowicz | 33 Comments
I’m really excited to see the 3.0 version of Sitecore PowerShell Extensions released. There have been more effort, love and sweat poured into this version by the whole team than I would ever expect. This blog has been written to assert the smoothest upgrade experience possible. While we’re always striving for the smoothest upgrade possible – this version introduces some changes that require you to perform a manual step or two. While those could be automated to a degree, making those manual was a conscious choice as I didn’t want to break e.g. your Insite instance that stores some of its files in the “Console” sub-folder of the Website folder.
Before upgrading your instance from Sitecore PowerShell Extensions 2.x to 3.0 please make sure you have your scripts backed up as the upgrade process might cause some of your scripts to be removed. This is especially true if you used the integration script libraries and you are upgrading from SPE 2.7 or earlier. If you’re upgrading from version 2.8 and your script live in your own modules You should be safe although it’s always smart to back up.
The steps you need to take prior or after installing the new version of the PowerShell Extensions:
You MUSTdelete the following folder from your sitecore Website folders:
\sitecore\shell\Applications\PowerShell\
IMPACT: If you will not delete that folder or the contents of that folder the PowerShell Extensions applications might no longer work or produce unexpected results
You SHOULDdelete the content of the following folder:
\Console\Services\
IMPACT: Should you not remove the folder – the PowerShell services might be available from both the old URL and the new URL available at: “\sitecore modules\PowerShell\Services\”
You CANdelete the following folders:
\Console\Assets\
\Console\Scripts\
\Console\Styles\
IMPACT: Those folders now exist under “\sitecore modules\PowerShell\” but their existence in the previous location does not have any impact other than taking space on the server,
That is pretty much it. I hope to blog about the new features shortly as there is plenty of them and the whole PowerShell Extensions team is really excited to make those available for you.
November 1st, 2014 by Adam Najmanowicz | 45 Comments
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 »
October 26th, 2014 by Adam Najmanowicz | 51 Comments
If you?re reading this, chances are you?ve probably read about the ways of putting scripts in the Content Editor ribbon or Context Menu. Those are some simple and quick ways of extending the Sitecore UI to do quick actions accessible for your users without them having to even know about the existence of PowerShell in your system. Up until now however we?ve not been very vocal about the fact that those does not really have to be quick one-off actions but they can indeed form a broader solution to your problem through the use of persistent, named sessions. In fact Sitecore PowerShell Extensions (SPE) allow you to manage sessions and decide that it should stay in memory after the script have executed. In fact SPE does quite a bit of session maintenance itself that you might want to be aware of.
What do I really need to know about script sessions?
ScriptSession is an object that encapsulates a PowerShell Runspace. Whenever you decide to run a script 2 things will happen:
a ScriptSession is requested from the SessionManager (which either creates a new session or recovers an existing named session)
after which it?s being used to execute your script in either the current thread or a new Sitecore Job is being instantiated and the Script session is passed to it for execution.
This is decided internally based on what you?re using a Session for unless you?re instantiating it directly (like described in this post) in which case you?re responsible for disposing it.
After the script is executed and the Job has ended the session is discarded unless your script has a Persistent Session ID which I will show you how to define in just a moment.
Great so there are sessions? but what are they good for?
October 25th, 2014 by Adam Najmanowicz | 75 Comments
Creating reports is probably a task that every developer dread. I for once always felt like listening to Tennessee Ernie Ford?s ?16 Tons? every time when I was supposed to do it for yet another project audit ? especially this part resonated with me:
I was born one mornin’ when the sun didn’t shine
I picked up my shovel and I walked to the mine
I loaded sixteen tons of number nine coal
And the straw boss said “Well, a-bless my soul”
While the Advanced System Reporter gets you a long way, I’ve found that there were still many scenarios where I would have to write the reports by hand. Madness? Fast forward to Sitecore PowerShell Extensions (or SPE for short) it actually this doesn?t have to be like that and creating reports can be both quick and fun ? provided you?re going to use the module.
Loading...
the module.
