-
-
Notifications
You must be signed in to change notification settings - Fork 176
add notes to create an emergency user #1703
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 7 commits
caf2251
b4273e2
6ca3507
c695357
8f92fa0
634806d
5fb84db
5b489d6
94baa83
33b3ad3
9d3abb9
6692187
f5fb944
b9157e3
247a999
64b80ca
c89eb53
45aa742
c661110
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
davisagli marked this conversation as resolved.
Show resolved
Hide resolved
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,64 @@ | ||
--- | ||
myst: | ||
html_meta: | ||
"description": "Create an emergency user" | ||
"property=og:description": "Create an emergency user" | ||
"property=og:title": "Create an emergency user" | ||
"keywords": "Plone, users, groups, emergency user, pip, buildout" | ||
--- | ||
|
||
(user-groups-emergency-user-label)= | ||
|
||
# Emergency user | ||
|
||
An emergency user is one that you can use to regain administrative access to a Plone site. | ||
If you lose the administrator password, or you inherit a project without proper documentation, you can create an emergency user. | ||
|
||
First of all, do the following steps not in a production environment! | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What would someone do in a Production environment? Are they out of luck? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Of course, you can do this operations in a production env, but you should not do this. ;-) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What should someone do in production instead? We can't say "don't do this", then in the next section say "do this". It's very confusing. Perhaps you can include what are the consequences and risks of doing this in production, aside from the obvious, specifically that the site will be down while adding the emergency user. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @1letter can you answer the following questions? I want to move this PR forward.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think I addressed these issues with #1854 I decided to talk about "Zope Manager Users", which IMO it is more appropriate than "Emergency users" There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @ale-rt @stevepiercy I like the change to extend the scope to "Zope Manager Users" and mention the "Emergency user", but the traditional term "Emergency user" should be highlighted in the text to reflect the purpose in production! I added this here, because of the context of the suggestion by @stevepiercy in my discussions with him and seperately with @jensens. But it needs to be seen also in context of the current preview: I would also enhance two things:1. Do not tag admin:admin "as usual":It is OK to use that for an instance fired up for testing and to be destroyed at once or soon or later before going to production. But it should be mentioned and made clear that for instances installed ending in production the password should be changed before anything goes into persistence. The consequences might be not obvious, but even behind a proxy the ZMI root may be reachable (like with Volto) and can lead to a permanent backdoor not easy to discover even not using admin:admin. Imagine a different user:password than admin/admin and the sysadmin / integrator changes and the httpauth in the ZMI backend is not changed or restored from a backup. Then an in fact unauthorízed person can try to gain access with these hardcoded credentials. 2. Prominent warning to immediately change default credentialsThere should be a prominent warning
Further considerations3. @1letter completely denied to use this in production.I am contrary because the emergency user purpose is still valid for emergency use cases like changed admins or lost credentials. The Challenge in production is, that the user is persistent in the database and therefore also in backups. So old backups are still accessible with the old credentials when restored without proper awareness and documentation of changes in access credentials including point in time. 4. Revamp random password as defaultIn the past there was an approach that the installers created a random password and wrote it into the filesystem when the initial password was not specified during install. When you removed the file, took a note in your password manager and changed the password at once no traces were left. Today these ways are deeply buried in e.g. docker containers and not easy to handle. Maybe this is a trap in automated deployments ongoing work on thisI am working on writing this up for cookieplone based docker deployments, but it is too early and would block the release of this PR. This can be added later. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Do you have suggestion on how to do that?
Uhm maybe here I am missing something. When you have access to the DB you can anyway change the password manually there. So I do not consider this a real issues.
I think this is extending the scope of this PR.
Agreed! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
@ale-rt The issue in my deployments was in place because the Cookieplone project template sets up a Traefik that creates a basicauth middleware and is created by a label in the docker swarm stack service backend. In my early attempts I tried to modify the deployment in the docker-compose.yml file, but the changes had no effect and seemed to be ignored in the redeployment. Today @pbauer, @tlotze and me went through the training docs for the deployment and weeded out lots of pitfalls in order of execution and issues related to images missing on the arm platform for servers. During these attempts it became clear that the initial modifications during setup were rolled out into the yml file in That said, the origin of the "persistent" basicauth is discovered and therefore the Cookieplone docs needs to be updated to point to the place for changing that. |
||
|
||
|
||
(user-groups-create-an-emergency-user-label)= | ||
|
||
## Create an emergency user | ||
|
||
There are two procedures to create an emergency user, depending on how you created and manage the Plone site. | ||
For both scenarios, the commands you run will stop the Plone site, add a new user, and start the Plone site. | ||
|
||
```{important} | ||
You should always stop your Plone site before adding a new user. | ||
``` | ||
ale-rt marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
```{important} | ||
The new username must not be an existing one. | ||
Therefore you should avoid the username `admin`, but use another arbitrary name, such as `admin2`. | ||
``` | ||
|
||
|
||
(user-groups-emergency-user-pip-installation-label)= | ||
|
||
### pip based Plone instance | ||
|
||
You can run the following shell commands to create an emergency user. | ||
|
||
```shell | ||
./venv/bin/instance stop | ||
./venv/bin/addzopeuser -c instance/etc/zope.conf <user> <password> | ||
./venv/bin/instance start | ||
davisagli marked this conversation as resolved.
Show resolved
Hide resolved
|
||
``` | ||
|
||
Now you can login with the created user. | ||
|
||
|
||
(user-groups-emergency-user-buildout-installation-label)= | ||
|
||
### Buildout based Plone instance | ||
|
||
With buildout and `plone.recipe.zope2instance`, you can run the following shell commands to create an emergency user. | ||
|
||
```shell | ||
bin/instance stop | ||
bin/instance adduser <user> <password> | ||
bin/instance start | ||
``` | ||
davisagli marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
Now you can login with the created user. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
--- | ||
myst: | ||
html_meta: | ||
"description": "Managing users and groups in Plone" | ||
"property=og:description": "Managing users and groups in Plone" | ||
"property=og:title": "Managing users and groups in Plone" | ||
"keywords": "user, groups, Plone" | ||
--- | ||
|
||
(backend-users-groups-label)= | ||
|
||
# Users and groups | ||
|
||
|
||
```{toctree} | ||
:caption: Users and groups | ||
:maxdepth: 2 | ||
|
||
emergency-user | ||
``` |
Uh oh!
There was an error while loading. Please reload this page.