Content Hub Gotchas: Avatar upload

-

So has been a long time between drinks for my blogging activities! I thought I'd try to get back in the swing by capturing some of the learnings from our current roll-out of Sitecore's Content Hub platform.

Content Hub is a pretty neat product, providing really good Digital Asset Management (DAM) capabilities along with MRM and what is called Product Content Management (PCM) which provides a light PIM capability. I think where it really shines however is in it's Content Marketing Platform (CMP) module. Perhaps more about that a little later.

If you are used to deploying a platform like Sitecore XP where you have access to the product binaries to dotPeek at, and get really detailed logs, debugging issues within Content Hub can be a bit of a laborious exercise. As a SaaS platform you only get the documentation (which although decent is never as detailed as you need it to be) and some fairly high level error logging. The system is very configurable too, which gives you plenty of scope for self sabotage if you are not very structured and methodical.

The problem

Today I was confronted with a bug report that there was an error uploading an avatar, with the very helpful error of "Upload failure reason unknown".

Upload failure reason unknown

Fortunately for me, the upload was working for one of our custom user roles (the owner role) but not others (the contributor roles) so I knew it must be a permission issue -- but what permissions on what entities?!

The investigation

My first step was to look at what happened when I uploaded an avatar through an account that worked properly.  I could see that, like most file-related operations in Content Hub when I uploaded a new avatar a pair of background jobs were being triggered:

Background jobs

Looking at the completed job, I could see that this was a standard file import job, and importantly the Fetch job gave me a clue with it's target...

Looking at the target ID, I was able to see in the entity viewer that the avatar was being uploaded not just as a file, but with an associated asset record. Furthermore I was able to see that the Asset was in the Approved lifecycle state, and that it was in a content Repository called "Avatar"

Surely this was enough to look at the permissions between the user that did and didn't work and see what that additional permission for assets in the Avatar repository was that I was missing -- or at least that I'd forgotten to scope an asset permission with the Standard repository somewhere?!

The complication

Alas -- if only it were so easy!

Looking at the asset permissions, I could see the following straight away:

  1. There were no permissions set for the Avatar content repository in either of the user permissions, including the permissions for the user that did work!
  2. The permissions for both the user group that worked and the one that didn't both had the Standard content repository set for all the permissions as expected
  3. Both the M.Asset and M.File permissions in both user groups were similar but different in precisely the way that would be expected based on their different requirements/li>

Was this some odd product bug? Does the Avatar upload depend on some esoteric and unexpected permission such as the ability to create an asset draft? Was it interacting with some other entity type in some way? Given no smoking gun, the only options was to go back to first principals debugging:

  1. Align the erroring "contributor" role to the exact permissions of the working "owner" role; and
  2. Make one change at a time and test until we found the culprit!

Stepping through both the asset and the file permissions one by one, I was able to determine that my original suspicions of a permissions issue relating to Asset or File objects was wide of the mark. The "contributor" permissions for assets and files, with the "owner" permissions for everything else were still working correctly!

The answer!

I have found using content hub that sometimes Page object permissions expose themselves in some unexpected way, so Page permissions were my next port of call. Working through the Page permissions I noticed a suspicious looking entry for the working "owner" role -- Avatar upload! Having a look at the Avatar upload page, it's one of those mysteriously annoying system managed entities in content hub. What does it do? Don't know!!

Nonetheless, checking the roles that showed the error I was able to confirm that none of them had it. Sure enough, adding Read permission to the Avatar Upload page solved my upload failure issue!

There isn't an additional page that is shown as a part of avator upload, so I can only posit that the page has some code that is run behind the scenes somehow during the upload process. Hopefully the Content Hub team will find time to update the error message!

Comments

Post a Comment

Popular posts from this blog

Cloud hosting Sitecore - High Availability

-
Image
The approach to hosting web facing systems has changed significantly over the last few years, with virtual machines almost completely replacing physical infrastructure.  These private cloud virtual server farms allowed server instances to be built and run on consolidated hardware, simplifying purchasing for IT departments.  This cloud computing pattern is generally known as Infrastructure as a Service (IaaS), and it simplified the way that physical hardware was purchased, whilst supporting the same approach to building and deploying applications that had been used before.  Public cloud hosted IaaS platforms remove the purchasing requirements, whilst providing a high degree of flexibility in how services are hosted, however IT teams still had to install and configure operating systems and other system software like content management and database systems the same way as with traditional environments.   Amazon Web Services and Microsoft Azure are currently the two leading IaaS cloud
Read more

Setting up TDS to work with Azure DevOps

-
Image
We recently had the challenge of moving across a legacy project, that we inherited, to run on Azure DevOps.  This project is five or six years old and still leverages TDS for packaging Sitecore items. Helpfully the code repository already had a copy of the nuget package contents checked in and referred to by the TDS project files, however this was designed to use an older version of visual studio (2015) than we had available as a part of the default Microsoft supplied build agent (2019).  In addition we needed to make sure the build agent was able to use our TDS license keys. Setting up the TDS license The old HedgeHog documentation has some good info on how to set up TDS to run on a build server.  This states to set up two environment variables: TDS_Owner and TDS_Key with the license information that the TDS tool will look for at runtime. Our first attempt to follow this instruction for DevOps was to create a powershell task to set the variables - task: PowerShell@2 displayName:
Read more

Sitecore - multi-site or multi-instance?

-
Image
I have been asked by a number of different people recently about when it is appropriate to maintain a number of different websites on a single Sitecore instance, versus deploying multiple Sitecore instances (on the same or separate hardware) to keep sites separate. As is usually the case, the answer is "it depends", but there are some key conditions that can lead to a clear choice between one over the other. Single Instance In the single instance approach, there is a single installation of Sitecore that hosts all of an organisations sites. This means that there is one IIS website hosting Sitecore per server all sharing the same Sitecore configuration and content. Pros Single set of user access credentials for access to all sites If you are not using LDAP integration for login to your Sitecore instance (or using some other customisation such as federated security through something like ADFS), having a single instance lets you use the same set of Sitec
Read more