How to disable "Register" and "Log-in" links on the login page?

XWiki 16.10.3

Searching has indicated that I need to make sure User & Rights > Rights > Users > Unregistered Users > Register is not selected to prevent the “Register” link from showing up on the login page.

Similarly, searching has indicated that I need to make sure User & Rights > Registration > Enable login button is not selected to prevent the “Log-in” link from showing up on the login page.

Neither of these approaches seem to be working, and I’ve confirmed that with these settings an unregistered user can register themselves and view our wiki content.

How can I remove these links and ensure that only users which have been added by admin have access?

Update
Sigh, the checkboxes under the User & Rights > Rights > Users > Unregistered Users > Register setting are not standard “binary” checkboxes. Instead, these checkboxes are ternary, having a green “checked” state, a red “x’ed”, and a blank “undefined” state.

Still need to figure out why the checkbox for enabling/disabling the login link (which is binary) isn’t working.

Hello,
have you consulted this page? https://www.xwiki.org/xwiki/bin/view/FAQ/HowDoIPreventUsersFromRegisteringThemselves
Maybe it can help you.

1 Like

Thanks for that. The link to register a new user in the instructions you linked to results in a The requested page could not be found page. For posterity, that link is:
https://xwiki.example.com/bin/view/XWiki/RegisterNewUser

On my version of XWiki (16.10.3) the new user registration link is:
https://xwiki.example.com/bin/register/XWiki/XWikiRegister

This got me thinking if I really had the registration permission correctly protected (spoiler, I didn’t). In the “Update” section of my OP, I provide a picture which shows how the checkboxes are ternary, and that you have to have a red X in the checkbox to disable the feature, otherwise the permission is whatever XWiki determines is the “default”. I had only set a red X for the registration permission on unregistered users. This means that any registered user or group that didn’t have a red X for the registration permission could still access the new user registration page. I.e. a non-admin user (a user with the lowest permissions) could have accessed the registration page and created a new user. To correct this, I made sure the XWikiAllGroup had a red X in the register permission. That looks like this:

Now the question is, what rights are set for the checkboxes which don’t have a check or a red X? We don’t know. Also, if you upgrade your XWiki instance and a default right changes, maybe a right which was previously allowed/denied by default now flips to a state you don’t want, and you don’t know until a problem arises because of it. I created this issue to address the problem:

https://jira.xwiki.org/browse/XWIKI-22897

In the mean time, I updated all group permissions to be explicit as seen in the picture below. If you are using XWiki in a context where security is a concern, I recommend you do the same:

With these settings, only admin users can register new users. All other users who attempt to visit the registration page will be met with the following:

Now I just need to figure out why the “Log-in” link still appears in the tool bar of the login page.

Thanks for that. The link to register a new user in the instructions you linked to results in a The requested page could not be found page. For posterity, that link is:
https://xwiki.example.com/xwiki/bin/view/XWiki/RegisterNewUser

Because it is an example, as the part in the link suggests : https://xwiki.example.com. So all you need to do is replace it using your own domain.

This way : https://your_own_domain/xwiki/bin/view/XWiki/RegisterNewUser

And from there try to follow the documentation page I provided you.

The page is fairly recent, (2024/03/07), it has to help you.

From what I understand, the other spots you show with your screenshots are irrelevant.
What I read on that page, which seem important:
protect this page under the More Actions menu.

Have you found the More Actions menu in that RegisterNewUser page? And if so, then have you noticed on that short documentation what comes next: _Two important cautions_.

Now I just need to figure out why the “Log-in” link still appears in the tool bar of the login page.

How do you expect to login when you need to work on your wiki if you don’t have a login button that leads to a login page?

Yes, I know to correct the URL to account for the domain name :slightly_smiling_face:. 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.

This is a bit misleading but if you read what it says it doesn’t do what you think it does. I says:

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.

This is about the registration process which can provide a log-in button after registering. It’s not about the login button in the UI at the top.

About the latter:

Hope it helps

1 Like

Yes that is good info, thanks! Do you also know the purpose of the “Log-in” link in the tool bar on the login screen?

can you post a screenshot?

Are you asking for a screenshot of the “Log-in” link I referred to? If so, the screenshot in my first post shows it.

Ok I get it now. It’s the link to the login screen! :grinning: The toolbar is the same independently of the page you’re in. It’s how you log in.

Now I agree that it could be an improvement to not display it when the user is on the login screen itself. Would be nice to raise a jira issue to report it.

Thx