Yes, I know to correct the URL to account for the domain name
. I also know to correct the URL to account for the app location (I.e., my XWiki instance is hosted from the “ROOT” directory, the example URL in the instructions you link to is hosted from the “xwiki” directory). What I’m saying is, that URL doesn’t work.
I dug into it a bit more and the problem seems to be with the “view” vs “register” segments of the URL. If I use the example URL from the instructions you linked to with the domain corrected and app location corrected (as I originally did), XWiki cannot find the page. I assumed that URL had just changed from between the time the instructions were written to now, but I re-tested it replacing “view” with “register” and that URL is valid. The difference I was trying to point out between the URLs in my previous post was the fact that the final URL segment for the URL that the “Register” link on the my login page points to ends with “XWikiRegister” where the example link in the instructions you provided ends with “RegisterNewUser”. As a concrete example, observe the URLs below whose app paths and domains have been normalized for easier comparison:
Works:
https://xwiki.example.com/bin/register/XWiki/RegisterNewUser
https://xwiki.example.com/bin/register/XWiki/XWikiRegister
Doesn’t work:
https://xwiki.example.com/bin/view/XWiki/RegisterNewUser
https://xwiki.example.com/bin/view/XWiki/XWikiRegister
As I stated in my previous post, the registration issue is resolved with the permissions settings I outlined. My solution allows the registration permission to be controlled globally instead of at the page level, which is more convenient I think.
Not talking about the “Log-in” button, talking about the “Log-in” link which there is a big red arrow pointing to in the first pic in my OP. That link, I assume, is what is actually being referred to by the setting User & Rights > Registration > Enable login button
which has the following description:
When the user has registered, we provide a button for them to click which will post their user name and password to the login action and get them logged in right away. This however causes the user name and password to be passed back in the HTML which may be unacceptable depending on your security needs.
Obviously I want users to be able to login, but from the description of this setting and empirical data gathered from testing, it is not clear what it actually does. Additionally, pressing the “Log-in” link (not the button) doesn’t appear to do anything regardless of this setting, the current log-in status of the user, or the value of the username/password fields, so I’m trying to remove it.