Follow-up: Consider if the page is accessible by current user before using simplified display

[indigoxela]

Description of the bug

Issue #6570 added simplified login path displays for three paths, Issue #6799 extended it to allow also the default theme to be used.

What we didn't consider:

If user registration is disabled on a site, this path will lead to a 403, but still with the simplified display (the admin theme) ... and that looks awkward.

Steps To Reproduce

Requires latest dev.

1. Go to admin/config/people/login and verify, the simplified display's turned on, using the admin theme
2. Go to admin/config/people/settings and verify that anonymous may not register accounts
3. In a different browser or a browser window without session go to user/register

Actual behavior

It's a 403, of course, as expected, but wow, that page looks odd.

The same weird display probably happens, when flood prevention strikes. Edit: it doesn't,

Expected behavior

If the site doesn't have user registration enabled, the simplified page display makes no sense for that path. Same if the page isn't accessible for other reasons. Deliver regular 403 pages instead.

Additional information

• Backdrop CMS version: 1.30.x-dev

[indigoxela]

Here's my idea: backdrop/backdrop#4984

@herbdool While this primarily prevents the odd display when user/register's not accessible, this might also fix the problem with TFA you described in our Zulip chat.

Edit: there's yet another time a problem with caching... The menu cache sticks. I have to save the "Account settings" form twice, so the delivery callback gets wiped again.

[indigoxela]

Some more digging and now the static cache no longer gets into the way. Phew.

Ready for testing and review.

[argiepiano]

Thanks, @indigoxela. This works great! A simple fix. WFM. I'll let @herbdool test with TFA and mark as RTBC.

[herbdool]

I love it when I wake up and not only is there an issue, but there's a fix! I'll test with TFA.

[herbdool]

I don't know if I need to fix something in TFA or in core, but now the rest of the TFA process looks worse.

I can't understand why system/tfa/*/* is getting access is FALSE, when it's not on an access denied page. And TFA has an access callback tfa_entry_access which is returning TRUE so it should be okay. I also stepped through the code and it is still able to find system/tfa/%/% even though backdrop_valid_path() gets passed system/tfa/*/*.