A big negative for Lando: security weakness, because it makes your entire home directory accessible (read/write) to anything running in the Lando container.
https://github.com/lando/lando/issues/2635#issuecomment-860211387
This behaviour seems to have maybe changed in some recent version, for Linux: on my Ubuntu 22.04 machine, I see an empty /user directory, when testing:
<code>
lando ssh
ls -al /user
</code>
But under MacOS, the documented behaviour is present.
Patch #6 worked for me - the warning "Missing proxy class 'Drupal\book_tree_menu\ProxyClass\oscBookManager' for lazy service 'book.manager'" was previously appearing after every drush cr, it's gone after applying the patch.
Reporting another successful result with current dev-4.x and Drupal 10.1.2.
One detail: about configuration of entityID, we previously had:
// Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
'entityID' => NULL,
It seems the NULL/undefined option is no longer supported - to achieve the same result, I needed to change that to:
// Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
'entityID' => "https://{$_SERVER['HTTP_HOST']}:443/simplesaml/module.php/saml/sp/metadata.php/default-sp",
Looks like there's a failing test, likely needs updating to match new logic
Confirmed - access tests were checking edit-own and delete-own permission based on revision uid rather than entity uid. I've changed that. I've also added a couple of tests cases to check update and delete when user has the edit/delete-own permission but is not the owner.
Before marking as RTBC, I think it's worth at least considering the possibility that somebody out there may have an access control strategy that would be broken by these changes. That seems very unlikely to me, but I suppose it's not impossible. In the worst case, people could get edit/delete access to micro-content that they're not supposed to be able to change. There's no simple solution - I'm just suggesting a pause for thought - maybe wait for a bit more input from others.
Looks like there's a failing test, likely needs updating to match new logic
Confirmed - access tests were checking edit-own and delete-own permission based on revision uid rather than entity uid. I've changed that. I've also added a couple of tests cases to check update and delete when user has the edit/delete-own permission but is not the owner.
Before marking as RTBC, I think it's worth at least considering the possibility that somebody out there may have an access control strategy that would be broken by these changes. That seems very unlikely to me, but I suppose it's not impossible. In the worst case, people could get edit/delete access to micro-content that they're not supposed to be able to change. There's no simple solution - I'm just suggesting a pause for thought - maybe wait for a bit more import from others.
I have learned: don't right-click the Open MR button hoping to check the URL - that will trigger the button action.
Andy Inman → created an issue.
We're also seeing this error with Authorization - Group 8.x-1.0 when trying to add a group.
Possibly related modules installed:
- Drupal Roles Authorization 8.x-1.0-beta6
- LDAP Authorization Provider 8.x-4.3
- Group (group) 8.x-1.5
I need to investigate further, and will post more info when I have it.