actually enforce that Guardian users have at grid_access permission

[twrichards]

#4270 added logging for users without any permission whilst we can get everybody's permissions in good shape.

What does this change?

This makes use of the hasAnyGridPermission val we created in #4270 for the result of the validateUser function. We also override the showUnauthedMessage function to return a more useful 403 response...

NOTE: as with #4270 this should be no-op for other organisations using Grid (since they'll be plugging their own AuthorisationProvider or relying on the default implementation of the key function hasBasicAccess which returns true).

How should a reviewer test this change?

Assuming https://github.com/guardian/permissions/pull/186 is deployed to CODE then deploy this branch to TEST main (or run locally) and experiment accessing grid with and without some form of grid permission (incl. new grid_access permission), observe the logs and you should see something like the image above.

How can success be measured?

adhering better to our security principles guardian/recommendations@b4746d4/README.md#security-principles

Who should look at this?

@guardian/digital-cms @guardian/newsroom-resilience @RichardLe @AndyKilmory @Conalb97

Tested? Documented?

• locally by committer
• locally by Guardian reviewer
• on the Guardian's TEST environment
• relevant documentation added or amended (if needed)

[github-actions]

Deploy build 12488 to TEST

All deployment options

• Deploy build 12488 to TEST
• Deploy parts of build 12488 to TEST by previewing it first

---

From guardian/actions-riff-raff.

[twrichards]

In #4270 we logged both whether the user accessing has grid_access permission and if not whether they have at least some other level of permission. There was only one user in the last two weeks who had the latter, so this PR actually simplifies to definitely require grid_access permission (see https://github.com/guardian/permissions/pull/186 - noting that grid_access permission is granted automatically based on some group membership)

CC @andrew-nowak given #4270 (review)

[andrew-nowak]

I think it would make sense to leave this unimplemented with a comment; it should be easy (one-line change) for other (existing or new) organisations to override with true in their implementations if they don't want to do authorisation checks while still making it an explicit decision (and less chance of accidentally leaving open unintentionally)

[twrichards]

hmm I did think about that, but didn't want the hassle/delay from other orgs implementing to delay this, after talking with you @andrew-nowak in person, I'll make the breaking change (which requires other orgs to implement in their plugged-in auth code) in a follow-up PR so I can merge this one now...

[prout-bot]

Seen on auth, usage, image-loader, metadata-editor, thrall, leases, cropper, collections, media-api, kahuna (merged by @twrichards 8 minutes and 33 seconds ago) Please check your changes!