Skip to Content
Last modified by Alexandru Pentilescu on 2023/06/25 18:56
From version 37.1
edited by Alexandru Pentilescu
on 2022/06/09 22:38
Change comment: There is no comment for this version
To version 47.1
edited by Alexandru Pentilescu
on 2022/06/09 23:25
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -247,7 +247,7 @@
247 247  Well, not quite...
248 248  There are still certain configurations which are a good idea that you should do. First and foremost, you should disable account registration, if possible, to ensure that rogue visitors don't get to pollute your database with bogus names. The user registration process is available to all visitors, by default, and this means that literally anyone can register an account on your Wiki. Which may be what you want or it might not be. For me, I prefer creating user accounts manually as the administrator so I opted to turn off the registration option. I suggest you do the same.
249 249  
250 -== Disable guest registration ==
250 +== Disable guest registration and configure unregistered users' rights ==
251 251  
252 252  Log into your administrative account if you're not already logged in. Press the hamburger menu button at the top right of the grettings page and open the side menu. From there, select the "Administer Wiki" option.
253 253  On the new page, expand the "Users & Rights" left panel and then click on the "Rights" menu option. You should then be redirected to a "Global Administration: Rights" page. Here, you can micro-manage the rights of every single user and groups of users. Explaining user rights and the exact functions of each of these options is outside the scope of this wiki. For now, I'll only describe the disabling of the registration.
... ... @@ -259,7 +259,41 @@
259 259  In our case, we wish to deny registration rights for unregistered users, so we have to set the "Registration" checkbox of the "Unregistered Users" row in that table to the "denied" state, like in the screenshot below:
260 260  [[image:Denied.png]]
261 261  
262 +I intentionally left the "View" and "Comment" rights specifically allowed for "Unregistered Users" as I believe that visitors should, intrinsically, have the ability to contribute to content as they see fit, without having to register for an account. You may wish to tweak these user rights as you see fit, though.
263 +If you will allow unregistered users to comment, though, please consider checking the checkbox below for requiring them to solve a CAPTCHA for each comment, like I did. This will prevent technically savvy individuals from writing automated scripts or bots that will access your wiki and continously and automatically keep generating machine-generated text comments. While this will not prevent humans from posting spam on your Wiki, it should prevent bots from doing so.
264 +
265 +
266 +== Configuring an SMTP server for your XWiki ==
267 +
268 +Having a reachable SMTP server that your XWiki instance can use may come in handy, at some point.
269 +The most obvious example of this is when you forget your XWiki user's password. When this happens, you will not be able to login anymore and, if this was the password for your administrator account, then, you're out of luck.
270 +Having the option to reset your password via email will be really useful in this particular case. Of course, this implies that the email you set during your account setup is not outdated and still in your control.
271 +To configure an SMTP server, go to the "Administer Wiki" section of the hamburger menu again, then expand the "Mail" section of the options on the left side and finally click on the "Mail Sending" menu option.
272 +[[image:Mail.png]]
273 +Of course, the exact configuration options you have to enter depend on your SMTP server's configuration. If you configured mandatory authentication on your SMTP server, you will have to enter login credentials here. I don't have to do that, personally.
274 +The "EMAIL ADDRESS TO SEND FROM" can be any email address you wish to configure. Preferrably, it should be under the domain name of the machine where you're running your XWiki from (in my case, under "pentilescu.com").
275 +The "EMAIL SERVER" option is a bit trickier. Assuming you're using postfix as your SMTP server, this should be an email configured in the "inet_interfaces" setting from the "/etc/postfix/main.cf" configuration file.
276 +Also, if your postfix is not configured to accept email relays from outside its network, as mine does, you must remember to edit "/etc/postfix/main.cf" to add "192.168.80.3" to its "mynetworks" configuration, to, essentially, whitelist your docker container as a valid relay source, otherwise it will deny any email sending requests from it.
277 +Please be sure to use the appropriate IP address as configured in your "docker-compose.yml" file for your xwiki service.
278 +For more information about postfix and setting it up, please visit the "How to setup a postfix SMTP server" article in the external references section at the bottom of this article!
279 +
280 +
281 +=== Correcting "localhost" directing URLs in received emails ===
282 +
283 +This might be just a problem on my end but, after configuring my SMTP server and then requesting an unnecessary password reset for my account to test my configuration, the arrived email contained a password-reset URL which, instead of pointing to my server, as it should have, it pointed to http://localhost:8081. This is obviously wrong and NOT correct.
284 +Fix: go to "<your XWiki directory>/data/xwiki-data/data/" and open the "xwiki.cfg" configuration file there. Find the "xwiki.home" configuration option in that file, uncomment it if you have to, and set it to point to your actual fully qualified domain name (including the trailing "/" at the end) to correct this issue. Please remember to restart the XWiki docker container afterwards for the changes to take effect!
285 +
286 +== Modifying cookie encryption keys ==
287 +
288 +XWiki has an interesting login mechanism. It doesn't use session tokens to keep track of your user account. What it does do is that it stores two session cookies in your browser: one for your username and one for your password.
289 +Every time you make a request to your server, these two session cookies are sent along with each request, effecitvely authenticating it.
290 +This might seem as a huge security problem, as the password is stored in the session cookie and it can be easily viewed by anyone with local access to the web browser's machine.
291 +To mitigate this security risk, XWiki encrypts both the username cookie's value and the password cookie's value using keys configured in a configuration file. These keys come with strong default values, by itself but, since these values are the same for everyone that downloads the docker image, are inherently public.
292 +As such, you, as the administrator, should change these encryption keys to your own, randomly generated ones. To do so, go to <your XWiki directory>/data/xwiki-data/data/ and modify the "xwiki.cfg" configuration file there. This file should have two configuration options called "xwiki.authentication.validationKey" and "xwiki.authentication.encryptionKey". Generate, from scratch, two different 32 character long encryption keys and replace the default ones with your ones. Uppercase and lowercase letters, as well as digits, are allowed. I don't believe other symbols are accepted though.
293 +Change these and restart the docker container, for the changes to apply.
294 +
262 262  = External references =
263 263  
264 264  [[Official docker guide for installing XWiki>>https://github.com/xwiki/xwiki-docker/blob/master/README.md]]
265 -How to setup an Nginx reverse proxy and also provide a global X.509 certificate for it -- NOT YET WRITTEN!--
298 +How to setup an Nginx reverse proxy and also provide a global X.509 certificate for it [NOT YET WRITTEN!]
299 +How to setup a postfix SMTP server [NOT YET WRITTEN]
Mail.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.AlexandruPentilescu
Size
... ... @@ -1,0 +1,1 @@
1 +156.4 KB
Content