Can you give us a bit more info on what can be exposed? Could it include login info / config files?

Hi, Is the problem an issue with ClientDependency itself, or the combination of Umbraco and ClientDependency?

Hi! We have Umbraco 6.1.6 with ClientDependency.Core of 1.7.0.4.

The update states the new version is fully compatible with 1.8.2.1. Will 1.8.3.1 be fully compatible with 1.7.0.4 as well?

Thanks!

I've tried to update from 7.4.1 but now i get an error regarding UmbracoDefaultOwinStartup.

We've overriden the Configuration method, but now we get the following error

Error   CS0246  The type or namespace name 'UmbracoDefaultOwinStartup' could not be found (are you missing a using directive or an assembly reference?) 

we are referencing Umbraco.Web, but this reference is apparently no longer used (since it's greyed out in Visual Studio)

What to do?

Hi there,

Tried to copy file over to bin on a 6.1.6 site and get the following error: Could not load file or assembly 'ClientDependency.Core - Copy' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Site is running .net 40 but I tried .45 and .35 as well just to be safe and same error on all 3. What am I missing?

Thanks, Phill

I appreciate you may not be able to answer this, but is the risk only to a single site being exploited, or all sites on a server that also hosts a vulnerable site?

We're trying to work out if we need to update all sites on a shared-hosting platform, or can prioritise "more important" ones.

Are previously updated sites also vulnerable?

For example when I have a website on Umbraco 7.1.2 and later updated this website to 7.5.9. The App_data ClientDependency folders are not cleaned right? So is it neccessary to clean the ClientDependency folders also for sites who were every before 7.2.2?

Just to be sure:

I also have "ClientDependency.Core.Mvc.dll" in my bin-folders.

This is not affected or should be updated?

Hi,

The nuget update removed this line from the web.config

<clientDependency configSource="config\ClientDependency.config" />

Can i add it back in or was that part of the security issue? just in terms of refreshing, I would normally bump the version in that file but now the version is stored in the web.config.

Cheers

Hi Sebastiaan,

We still manage an Umbraco website running version 4.7.1.1.

Noticed this version didn't appear in your original post. Is that version affected? If so, is it ok to update the ClientDependency.Core.dll to version 1.8.3.1? If not, do you have any suggestion on how to patch it?

Thanks.

Hi there

Two questions:

1. Are there any security risk if the backoffice is not publicly available?
2. Is it compatible with ClientDependency.Core.dll v. 1.5.0.1?

Thanks in advance!

We've recently inherited a v6.2 Umbraco site. The security alert lists this as a version that needs to be updated however the version of ClientDependency.Core that is running in the site is 1.8.4.

I'm guessing that we don't actually need to do anything as the ClientDependency.Core we're upgrading to is 1.8.3.1?

We are running Umbraco 6.2.6 and after updating the clientdependency package to 1.8.3.1 it has made a few changes to the web.config. Should all the changes to this file be reverted?

Thank you.

Not so much a question, but for other peoples info:

After I upgraded to the newest clientdependency version (1.9.2.0) it failed to properly handle a JS file missing a semicolon. That was on an Umbraco 7.2.1 site.

In my specific case it was the MultiUrlPicker.js that lacked a semicolon after the 'use strict' line (line 1 in the file). That broke stuff, so the login page into umbraco backoffice stopped working on my site :)

So, just an FYI if anyone else has some problems with the newest version av CliendDependencyHandler :)

/Mats

Updating ClientDependency for many sites

If you are like us, both a hosting and a web site developing company you may have both a version control and one or more production servers with several Umbraco sites.

Like Sebastiann points out in a comment further below the ideal approach would be to update version control, then publish the site to the production server.

With tens, maybe hundreds of sites in both version control and on one or more production servers this may not be the most convenient approach of updating ClientDependency.Core.dll.

We run on Windows based systems so I have managed to semi-automate this with the help of Team Foundation Server (TFS) command line commands and Powershell scripts.

My approach is:

1. Update ClientDependency.Core.dll in all bin folders on the production server with new version
2. Delete all files in App_Data\Temp\ClientDependency
3. Update all bin folders in version control with new version

Update production server

Windows Powershell convenience scripts for:

1. replacing all ClientDependency dll's older than 1.8.3.1 in all bin folders
2. deleting all files in ClientDependency folders

under c:\inetpub\sites (adjust for your source folder)

Disclaimer: use at own risk - check what will be targeted first.

#Print version of ClientDependency
gci c:\inetpub\sites -rec -filter bin | where {$_.psiscontainer} | gci | where {$_.Fullname -match "ClientDependency.Core.dll"} | foreach-object { Write-host $_.Fullname $_.VersionInfo.ProductVersion}

#Replace version < 1.8.3.1 with new version
gci c:\inetpub\sites -rec -filter bin | where {$_.psiscontainer} | gci | where {$_.Fullname -match "ClientDependency.Core.dll"} | where {[version]$_.VersionInfo.ProductVersion -lt [version]"1.8.3.1" } | 
foreach-object { 
    $target = $_.DirectoryName
    #Write-host $target
    Copy-Item C:\Users\Administrator\Downloads\ClientDependency.Core.1.8.3.1-net40\ClientDependency.Core.dll $target
    #Write-host $_.Fullname $_.VersionInfo.ProductVersion $_.DirectoryName
}

#Print all files in ClientDependency folders
gci c:\inetpub\sites -rec -filter ClientDependency | where {$_.psiscontainer} | gci

#Remove all files in ClientDependency folders
gci c:\inetpub\sites -rec -filter ClientDependency | where {$_.psiscontainer} | 
foreach-object { 
    #Copy-Item C:\Users\Administrator\Downloads\ClientDependency.Core.1.8.3.1-net40\ClientDependency.Core.dll $_.DirectoryName
    #Write-host $_.Fullname
    $path = $_.Fullname + "\*"
    #Write-host $path
    Remove-Item $path
}

Update Version Control

Steps:

1. Get fresh version of ClientDependency.Core.dll for allsolutions/projects
2. Checkout for edit
3. Replace ClientDependency.Core.dll with new version Check in new version of
4. ClientDependency.Core.dll for all solutions/projects

First start Developer Command Prompt for VS20XX:

• Windows button
• Type "dev"
• The Developer Command Prompt should appear

The change directory to your working folder that your version control files are mapped to

• cd c:\Work

1. Get fresh version

tf get ClientDependency.Core.dll -recursive

2. Check out for edit

tf checkout ClientDependency.Core.dll /recursive

3. Replace ClientDependency.Core.dll with new version

Run the Powershell script above but this time on your dev server where you have checked out from version control

4. Check in new version of ClientDependency.Core.dll

Ah yes, this is a good point. If you've updated all your sites by only dropping in the new dll then at some point in the future if you deploy to that site from source control again, you may overwrite it with an older version. Always make sure you update both your "deployment source" and the live site (ideally you would deploy from source control to live, like you "normally" would).

We have a customer running Umbraco 4.9.0 and after the update of ClientDependency pages are marked with a star in the backend, even after it has just been published.

Is that in any way related and now can it be fixed?

is working on a reply...