Support the logged_in protect schema

[jasonvarga]

It existed in v1.

protect:
  allow:
    logged_in: true

[iDGS]

Copy-pasted this from Slack, just to let yaz know I'm still (very) interested:

Back in v1, we could "protect" pages by putting like so

_protect:
  allow:
    _logged_in: true

in a page's yaml front matter. I had it wired up so that if you weren't logged in, you'd first be teleported to the log-in page with a return ticket in the URL, thus,

/login?return=%2Fthatpageyouwantedtosee

so once you did log in, you'd fly back to that "protected" page and get to see it.

Now, AFAICR, @jason some time ago said something like it's lack in v2 was an "oops" oversight, and it was going to get fixed (at some point).

So, question being: did it get fixed? Will it work? And if so, is it documented somewhere? (I'm a little wary of v1 vs v2 differences, so I'm asking before trying the head-banging thing this time around. 🙂

emd:
Not fixed
@iDGS

chrisburton:
middleware could be a solution for that (just sayin’ 😁)

[jasonvarga]

Almost done, it'll probably be in 2.6.

[iDGS]

That'd be great!

Any plans on (eventually, if not right away) allowing compound conditions, such as, say, both logged in AND role of admin? E.g., (and please correct my notation if I'm not doing this right)

protect:
  allow:
    logged_in: true
    role: admin

or logged in and any one out of a set of roles? E.g.,

protect:
  allow:
    logged_in: true
    role:
      - admin
      - editor
      - blogger

T'would would save me tons of extra coding.