Able to use Client ID/Secret from ENV?

The connection is made via OAuth per-environment. You have to manually connect the site to the DAM using OAuth. These are stored in the state table. It's the same approach that other integrations (like Salesforce) use.

The Client ID and Secret are shared and non-confidential. Unless you are using refresh token flow. Then you can use normal configuration overrides to store the values.

Does that answer the question?

@mlgaman Thanks for the reply!

I'm interested in using the configuration overrides to store the values. We want to use the refresh token flow but store the keys in .env files.

Does that make sense?

I'm trying this right now in a settings.php file:

  $config['acquia_dam.settings']['auth_type'] = 'refresh_token';
  $config['acquia_dam.settings']['client_id'] = getenv('WIDEN_CLIENT_ID');
  $config['acquia_dam.settings']['client_secret'] = getenv('WIDEN_CLIENT_SECRET');

But it does not appear to work as I would expect. The "Refresh Token" radio button is not selected and the two OAuth fields are empty.

I also tried commenting out the "getenv" functions and pasting in the key directly, but that did not work either.

Just a heads up: The refresh token flow is something that must be enabled on your DAM instance and those values provided to you. If that's already the case, perfect. I just wanted to take an extra step to clarify.

As for the display in the form, I don't believe Drupal _actually_ renders config overrides in forms. It explicitly strips away any overrides. For Drupal Commerce we generally recommended folks save bogus values in the exported config entity, knowing that config overrides would take place. I think there are some contributed modules that try to fix/improve this user experience. (I know I have seen it, but cannot recall its name or find it quickly via search.)

The way to test is using Drush and config:get --include-overridden acquia_dam.settings to verify the values are being read.

Okay, I believe I have now set it up correctly. Thanks for the advice!

I do have a follow up question. When the authentication method is set to a request token, why does the site still need authenticated to a single user's account?

Basically, we're getting hung up with Behat tests, when they try to attach a Media image to a field in a few tests they run into the modal message that asks to authenticate the site. I'm hoping there is a way to avoid this completely. Is that possible?

It's user access control. Users may be limited to a subset of assets in the DAM based on their permissions.

We have examples in our PHPUnit tests for faking the access token so that the media library loads results. You could mimic our tests or use them as inspiration for testing the integration end-to-end.

Gotcha.

I'll try and see what we can do about it, but regardless, this ticket can be considered resolved.

Thanks for your help!!

Just another thought on the matter:

I think it would be a better user experience if the "Select media source" dropdown defaulted to the "Media Types" selection, allowing the user to always be able to select internal site assets, and only prompted authentication when the "DAM" source is selected.

It seems like the module is coded to show the authentication prompt the first time a user ever opens a media modal window.

It would selfishly solve my issue I'm still having, but I think it would be a better experience overall.

I'm going to close this as Fixed, for the original request.

It seems like the module is coded to show the authentication prompt the first time a user ever opens a media modal window.

Correct. This was a decision made by product after conducting user interviews.

If you want, could bypass this by decorating the AcquiadamAuthService service to have shouldShowAuthorizationPrompt always return false or by calling markAuthorizationPromptShown when a user is created as a workaround.

You can also file that as product feedback through Acquia channels, or as a Feature request in this project and it will be routed appropriately.

Automatically closed - issue fixed for 2 weeks with no activity.