-
-
Notifications
You must be signed in to change notification settings - Fork 403
Description
Description
When a file is uploaded via a Workflow Attribute that utilizes a Binary File Type with IsSecure (Requires View Security) enabled, the file cannot be downloaded—even by Administrators—resulting in a 403 Forbidden error.
Investigation reveals that files uploaded via Workflow Attributes do not update the BinaryFile table with the ParentEntityId of the Workflow instance. They remain "orphaned" (ParentEntityId is NULL). Consequently, when GetFile.ashx performs the security check for a Secure File Type, it fails to find a parent entity to verify permissions against and defaults to Deny.
Actual Behavior
The file is saved to storage and the GUID is saved to the Workflow AttributeValue, but the BinaryFile record leaves ParentEntityId and ParentEntityTypeId as NULL. Because the File Type is "Secure," Rock attempts to check the parent entity's security. finding NULL, it blocks access.
Expected Behavior
When a file is uploaded to a Workflow Attribute, the system should associate the BinaryFile record with that Workflow instance (setting ParentEntityTypeId to Workflow and ParentEntityId to the WorkflowId). This would allow GetFile.ashx to validate that the user has permission to view the Workflow, and subsequently serve the file. Alternatively, update the security check process so that if ParentEntityTypeId and ParentEntityId then parent security in not required.
Steps to Reproduce
Go to Admin Tools > General > Binary File Types.
Create a new File Type (or use an existing one) and ensure Requires View Security (IsSecure) is Checked.
Create a Workflow Attribute of field type File.
Configure the attribute to use the Binary File Type created in Step 2.
Run the Workflow and upload a file to this attribute.
Attempt to view/download the file using the direct link (e.g., GetFile.ashx?guid=...).
Result: 403 Forbidden error, even if the user is an Admin and has View rights to the Workflow and BinaryFileType.
Technical Investigation: Running the following SQL on the file GUID confirms the orphan status:
SQL
SELECT
f.Id,
f.FileName,
bft.RequiresViewSecurity AS [IsSecure],
f.EntityId, -- Returns NULL
et.FriendlyName -- Returns NULL
FROM BinaryFile f
JOIN BinaryFileType bft ON f.BinaryFileTypeId = bft.Id
LEFT JOIN EntityType et ON f.EntityTypeId = et.Id
WHERE f.Guid = 'ERROR_GUID_HERE'
Workaround: A generic SQL update is required to manually link the files to the Workflow instances:
SQL To Fix All Binary Files in Attribute
UPDATE bf
SET
bf.ParentEntityId = av.EntityId,
bf.ParentEntityTypeId = (SELECT Id FROM EntityType WHERE Name = 'Rock.Model.Workflow')
FROM BinaryFile bf
INNER JOIN AttributeValue av ON bf.Guid = TRY_CAST(av.Value AS UNIQUEIDENTIFIER)
WHERE av.AttributeId = [AttributeId] AND bf.EntityId IS NULL
SQL to Fix "Current" Workflow
UPDATE BinaryFile
SET
ParentEntityId = @WorkflowId,
ParentEntityTypeId = (SELECT Id FROM EntityType WHERE Name = 'Rock.Model.Workflow')
WHERE Guid = TRY_CAST(@FileGuid AS uniqueidentifier)
AND (ParentEntityId IS NULL OR ParentEntityId != @WorkflowId)
Issue Confirmation
- Perform a search on the Github Issues to see if your bug is already reported.
- Reproduced the problem on a fresh install or on the demo site.
Rock Version
Rock McKinley 17.5
Client Culture Setting
en-US