Looking again at Login to View. It is now 5 years since this feature was originally added. So, taking a look at it to remind ourselves how it is configured, and how it works, and if it works the way we expect.
reference
Original pull request - github 
We imagine controlling visibility of wiki pages on a site or farm similar to operating a server on a private LAN but using distinguished logins rather than network access.
Login to View references Register Plugin via Registration Workflows. *It should be noted that the register plug-in has seen changes since the original login to view to tailor it for use with the friends security plugin.*
There are two open github issue/PR looking at using a custom Login Required page, but providing a method of extending the default pages.
* Custom "Login Required" text for restricted Sites , and
* Configure to overlay defaults from site .
.
Login to View is part of the `wiki-security-passportjs` package. Code on github
Although little is written about configuration, there are some examples in the linked github pages.
The parameters used are :-
- restricted
- set to true to restrict access to logged in users.
- allowed_domains
- an array of email domains that will be granted access.
- details
- a URL link to a page with details shown when accessed without being logged in. default page .
Let's try this locally, using caddy with private cert, and the localtest.me domain (which just points to loopback 127.0.0.1).
The configuration makes * uses Google for authentication, * requires `https:` for login *this is actually a Google requirement*. * user's cookie will only be shared over `https:`. * `localhost.me` and all its subdomains login to view, * require the user to have an email in `gmail.com` domain.
{ "farm": true, "security_type": "passportjs", "google_clientID": “secret.clientID….apps.googleusercontent.com", "google_clientSecret": “client…secret…”, "wikiDomains": { "localtest.me": { "restricted": true, "allowed_domains": ["gmail.com"], "security_useHttps": true, "secure_cookie": true} } }
**Some observation:**
As an unauthenticated user I get `Login Required` as expected when accessing a claimed wiki, but get `Welcome Visitors` if the wiki is unclaimed.
An unclaimed wiki can be claimed by anybody with a Google login, not restricted by `allowed_domains`!
As a user in an allowed domain, starting from the `Login Required` page, and logging in. The login completes with the padlock open, or tilted if I'm not the owner, and still showing `Login Required`. Requiring a page reload to get to `Welcome Visitors`.
As a user from a different domain, starting from the `Login Required` page. The login completes, with the padlock tilted. A page reload stays with the `Login Required` page. *If accessing a wiki owned by this user, the padlock is open and a page reload required to get to `Welcome Visitors`.
As an authenticated user, with an email address with the right domain. Access a wiki I'm the owner of shows `Welcome Visitors`. However access a wiki either unclaimed, or claimed by somebody else, I get shown `Login Required`. Again this appears to be wrong.
The client appears to fail when fetching sitemaps, and I assume indexes, for other wiki that have login required.
**Some thoughts:**
There seem to be two different behaviours going on here.
Allowing some external person to create a wiki, but not see content of other wiki. I have a memory of this being an original requirement, to provide a trusted person from outside to share content. If still required `allowed: '*'` should be used to prevent misuse.
Failure to fetch the sitemaps and index for remote wiki that are also login to view, looks to be caused by the request of favicon and sitemap having a 200 response, and not the 'Not Found'. This means that the it is not recorded that the remote site requires credentials to be passed with requests.