Provide constants for hook_file_download() return values

Created on 14 September 2016, over 8 years ago
Updated 27 May 2025, 5 days ago

Problem/Motivation

The docs for hook_file_download() read:

If the user does not have permission to access the file, return -1. If the user has permission, return an array with the appropriate headers. If the file is not controlled by the current module, the return value should be NULL.

Returning magical intergers is not very self-documenting. There does not appear to be an existing constant we can use in the file module itself.

Proposed resolution

We could do some of the following:

  • Add a constant (possibly to FileDownloadController?) Might be named something like FILE_DOWNLOAD_DENY or (if on the download controller) DENY.
  • Discuss whether the NULL "ignore" return value also merits its own constant.
  • Refactor to use some generic access result mechanism. There might be limitations on what we can do in a minor, even with an upgrade path, but it is worth looking into.

Remaining tasks

TBD

User interface changes

N/A

API changes

TBD

Data model changes

TBD

📌 Task
Status

Active

Version

11.0 🔥

Component

file.module

Created by

🇺🇸United States xjm

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • First commit to issue fork.
  • Merge request !12249Add constants for file download status. → (Open) created by mohit_aghera
  • 🇮🇳India mohit_aghera Rajkot

    Add a constant (possibly to FileDownloadController?) Might be named something like FILE_DOWNLOAD_DENY or (if on the download controller) DENY.

    I've added the constant for the controller.

    I initially though of using the Enum for this one, however since it was just one case, I didn't thought of using this.

    Discuss whether the NULL "ignore" return value also merits its own constant.
    

    I feel we don't need this one.
    I did a quick check in core grep -rn --include="*.php" -E "const\s+\w+\s*=" core/ and didn't found any such instance.
    Probably we've avoided in past?
    Happy to do that if we want to go that route.

    Refactor to use some generic access result mechanism. There might be limitations on what we can do in a minor, even with an upgrade path, but it is worth looking into.
    

    @xjm I'm slightly unclear about this one.
    Can you please provide more information.

  • Pipeline finished with Success
    4 days ago
    Total: 454s
    #507336
  • 🇦🇺Australia mstrelan

    I was thinking about this earlier and the parallels to AccessResultInterface. The equivalent here would be AccessResultForbidden for -1, Neutral for NULL and Allowed for the array return. Having a similar interface would properly restrict what can be returned from this hook. The awkward part is that this hook does two separate things, as per its documentation:

    Control access to private file downloads and specify HTTP headers

    .

  • 🇮🇳India mohit_aghera Rajkot

    I was thinking about this earlier and the parallels to AccessResultInterface. The equivalent here would be AccessResultForbidden for -1, Neutral for NULL and Allowed for the array return. Having a similar interface would properly restrict what can be returned from this hook.

    This totally makes sense to me. I can refactor this one.

Production build 0.71.5 2024