media_library filter giving Access denied

I think this is a bug. I am having this issue as well. I am on 8.8.2

same here - despite being logged-in as admin. Which modules do you have installed? Maybe there is a contrib module causing this?!

We have a lot of test coverage of the media library, and we also test the filtering, so I imagine that there's gotta be something else going on here. Did you modify the media library view in some way? Could it be a contrib module interfering? Can you reproduce this with a plain installation of Drupal core (and no additional modules)? Postponing this until we have more information.

On second thought...I'm un-postponing this. We do have steps to reproduce, so it's worth trying on a plain installation of core before we decide we need more info.

I tried to reproduce this issue on both Drupal 8 (8.9.3) and 9 (9.0.5), but everything seems to be working properly. I think @phenaproxima is right, there might be some details missing from the setup, so it would be useful to get more info about this.

Well, then! Thanks for looking into that, @bbu23...sounds like we should postpone this until more details are given.

I'm having a similar issue. I don't know if my setup is exactly the same but I have noticed the media widget works if you close it and re-open it again. So

1. Click 'Add media'
2. Media library modal opens but buttons don't work, applying a filter leads to 'Access Denied', media items cannot be selected
3. Close modal
4. Click 'Add media' again
5. Media library modal functions normally

The strange thing is I'm not getting any JS errors nor is there anything in the error log

I am having similar problem.
Logged in as administartor, and when I create a new media item, I can save it and it appears on the admin/content/media
But when I click the "media name" which should open the media for example here: media/18/revisions/18/view
It gives "Access denied"

So even administrator user can't open it, but can delete it.

This is the error message in dblog

Path: /media/19/revisions/19/view. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 117 of /var/www/html/site/web/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).

I'm having a similar issue to #10.

I noticed that when first opening the modal the media_library.ui.js file is not called, so when we close it and reopen the modal, media_library.ui.js is called and the filters work fine.

My testing process is the same as #10 :

1. Click 'Add media'
2. Media library modal opens but buttons don't work, applying a filter leads to 'Access Denied'.
3. Close modal
4. Click 'Add media' again
5. Media library modal functions normally, and my console.log in media_library.ui.js works

Hope this can help to understand where this is coming from.

Hello,
I have the same issue.

i noticed the same behavior as #12

After further testing

Tested with aggregate JS on.
Access denied occurs

Tested with aggregate JS OFF.
No Problem

Tested with aggregate JS on.
Access denied occurs

Thanks for trying this out! I'll give it a manual test today and see if I can reproduce with that.

So, i tried multiple things and i managed to get it working again.

I excluded all views js from aggregation and the media library filter works again. No more access denied.

/**
 * Implements hook_js_alter().
 */
function module_name_js_alter(&$js) {
  if (\Drupal::service('router.admin_context')->isAdminRoute()) {
    // Do stuff.
    foreach ($js as &$values) {
      if (strpos($values['data'], 'views/js') !== FALSE) {
        $values['preprocess'] = FALSE;
      }
    }
  }
}

If you have reset button and you have media field in content type when you try to add the media from that content type and that screen if you press the reset button you will land on /admin/content/media-widget there you see Access deny page. even if you admin you will see this msg. I tried with fresh installation its same.
Error from DBLog
Message Path: /admin/content/media-widget. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: The opener ID parameter is required and must be a string. in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 117 of E:\wamp64\www\drupal8\core\lib\Drupal\Core\Routing\AccessAwareRouter.php).

I have disable cache and disable aggregation Js and CSS.

If you have reset button and you have media field in content type when you try to add the media from that content type and that screen if you press the reset button you will land on /admin/content/media-widget there you see Access deny page. even if you admin you will see this msg. I tried with fresh installation its same.
Error from DBLog
Message Path: /admin/content/media-widget. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: The opener ID parameter is required and must be a string. in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 117 of E:\wamp64\www\drupal8\core\lib\Drupal\Core\Routing\AccessAwareRouter.php).

All of that sounds like it works exactly as designed. You're not supposed to visit the media library view at its own page (/admin/content/media-widget); that path is used only in the media library modal, and it requires certain conditions to be present (i.e., some request parameters and hashes and stuff), or it throws errors and exceptions.

Hi, just wanted to add that I'm getting the same behaviour as #17.

And just to clarify

All of that sounds like it works exactly as designed. You're not supposed to visit the media library view at its own page (/admin/content/media-widget);

@phenaproxima I can reproduce the issue using the media library widget, all settings as default, only adding a reset button to the view exposed filters options.

Once you click on "reset" instead of resetting the exposed filters, it redirects the entire page to the widget page, with the exposed filters set, like: /admin/content/media-widget/document?name=sample&sort_by=created&op=Reset and that page gives, as expected, a 403.

Attaching view config and adding screenshot

The only change in the view was adding the reset button, like:

exposed_form:
        type: basic
        options:
          submit_button: 'Apply filters'
          reset_button: true
          reset_button_label: Reset
          exposed_sorts_label: 'Sort by'
          expose_sort_order: false
          sort_asc_label: Asc
          sort_desc_label: Desc

Adding related issue in Better Exposed Filter module as the latest patch in #65 seems to fix this issue (that's coming from Core) on that contrib and it may be helpful here :)

I'm getting this permission error for medial field modals launched inside the layout builder, but I'm not using better exposed filters. I'm running drupal core 9.2.7, this issue seemed to pop up after I added some patches to address other issues coming from query related things:

Issue #3065095: CKEditor table properties not clickable due to interaction with jQuery UI dialogs

https://www.drupal.org/files/issues/2021-09-30/3065095-31.patch

[PP-1] Drupal.ajax does not guarantee that "add new JS file to page" commands have finished before calling said JS

https://www.drupal.org/files/issues/2021-05-27/1988968-228--9.2.x.patch

update: removing patch for #3065095 seemed to fix the permission issue I ran into

We are having the same issue. It seems that media_library.ui.js is not getting attached when the media library modal is loaded. This only occurs when js is aggregated. I don't know if this is an issue with aggregation, or with how the library gets included. But that file is at the heart of why things are failing.

This is also related: https://www.drupal.org/project/drupal/issues/3081319. When that js file is not loaded, it doesn't set the hidden field '#media-library-modal-selection' and thus it doesn't properly get the selected IDs in the updateWidget function.

Someone mentioned this workaround, to remove the file from aggregation:

function custom_module_js_alter(&$js) {
  if (isset($js['core/modules/media_library/js/media_library.ui.js'])) {
    $js['core/modules/media_library/js/media_library.ui.js']['preprocess'] = FALSE;
  }
}

And this works, but I would rather solve this at the core, rather than using some workaround.

We're experiencing the same issue. I can confirm that disabling javascript aggregation fixes the issue for us.

$config['system.performance']['js']['preprocess'] = FALSE;

We had the precise same issue as #10.
Switching JS aggregation off did not solve the problem.
The patch at comment #268 on https://www.drupal.org/project/drupal/issues/1988968#comment-14385028 did solve it.

I have the same issue after update Drupal core from 9.4.7 to 9.4.8.

Also issue exists on clean Drupal 9.4.8 with media library enabled.

None of workarounds or disabling aggregation not fixing the issue.

Seeing this as well. none of the workarounds or fixes are working.

Issue was fixed by applying the `core-ajaxload-1988968-338.patch` patch from https://www.drupal.org/project/drupal/issues/1988968#comment-14636967

`Drupal version : 9.4.3`

I'm not totally sure this is the same problem but I'm still getting access denied on admin/content/media-widget-table in D 9.5.8

The error in the logs is

Path: /XXXX/en/admin/content/media-widget-table. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: The opener ID parameter is required and must be a string. in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 118 of /XXXX/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).

still an issue D 9.5.10

The error in the logs is

Path: /XXXX/admin/content/media-widget/image?name=xx&sort_by=created.Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: The opener ID parameter is required and must be a string. in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 118 of /XXXX/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).

When we ran into this issue it was for a piece of content that had maybe a hundred paragraphs, most with images in them— but i think it is reasonable to expect that what happens in any given media widget should be unaffected by the context from where that widget was called.

And the cause was this, as found in the Apache web server log:

Got error 'PHP message: PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0', referer: https://example.com/node/16/edit

Increasing max_input_vars to 2000 fixed it for us.

Should this be closed out?

This is still and issue, with Drupal 11.2.5

On a node edit screen, trying to add media to a field.

I get the media modal which lists things in a grid, and I type some text in to the filter, to search by title.

/admin/content/media-widget/image?name=Cog&sort_by=created

This path, logged in as UID 1, admin.

Results in an access denied.

Path: /admin/content/media-widget/image?name=Cog&sort_by=created. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: The opener ID parameter is required and must be a string. in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 114 of /code/web/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).