Add failsafe_login and fallback_login on page /admin-guide/zope-manager-users.html

[acsr]

If you are trying to login into a production or development site that has plone.pas (pas = plugable auth system) plugins installed, it is maybe difficult to bypass the authenthication to manage setups as an admin, in particular if those authenthication methods are broken due to failure of a service or other circumstances.

This is a draft to be propagated into a PR after reviewing the concept and possible location in the docs.

currently you cannot find either failsafe_login or fallback_login using the search in the docs.

Collected information from my experience today (with some help by Jens Klein and agentic search in the web.

How to use a proper login when a plugin blocks entering credentials during development or emergency

To avoid getting caught in a loop or trap there are special login urls, that allow to bypass the optional login procedures and fallback to the rudimentary methods of Plone.

• You can try to login at the Zope level ZMI Root if accessible for you
  • you can use the addzopeuser command based procedures with filesystem access to add additional admin users
• In the Plone Classic UI you can use https://example.com/failsafe_login to enter the original input form for user ID/E-mail + password.
• To allow that in Volto there is the different url https://example.com/fallback_login.

There are other methods once you have access to the ZMI to disable the other methods. But this needs going futher.

Option 1: Use

failsafe_login or fallback_login (easiest)

Plone has the built-in emergency login forms that bypasses the normal login challenge (including OAuth redirects). Just navigate directly to:

http://localhost:8080/Plone/failsafe_login (Classic UI)
http://localhost:3000/fallback_login (Volto)

This renders the classic username/password form regardless of what PAS challenge plugins are active. Use your admin credentials here. It's the quickest workaround for local dev.

---

Option 2: Log in via the ZMI directly

The Zope root admin user lives outside the Plone site's PAS entirely, so it's not subject to pas.plugins.authomatic etc. at all. Access it at:

http://localhost:8080/manage

Log in with your

admin(x) / password (or whatever you set in instance.yaml). From the ZMI you can then navigate into the Plone site, manage users, reset passwords, etc. (Plone Volto can be a challenge, then you can use Option 1 from there.

---

Option 3: Use the REST API to get a JWT token

Since the backend exposes plone.restapi, you can authenticate directly against it with a POST to @login:

curl -X POST http://localhost:8080/Plone/@login \
  -H "Content-Type: application/json"\
  -d '{"login": "admin", "password": "admin"}'

If the standard HTTPBasicAuthHelper and ZODBUserManager PAS plugins are still active (they should be — authomatic only adds an OAuth path, it doesn't typically remove the password plugin), this will return a JWT token you can use for subsequent API calls.

---

Option 4: Temporarily disable the authomatic challenge plugin via ZMI

If the issue is specifically that the challenge plugin from authomatic is intercepting your login and redirecting you to GitHub before you can enter a password:

1. Go to

http://localhost:8080/Plone/acl_users in the ZMI
2. Click on authomatic (the plugin)
3. Go to the Activate tab
4. Uncheck Challenge (leave Authentication active if you want OAuth to still work for other things)
5. Save

This will stop it from hijacking the login flow, so the standard login form will show again. You can re-enable it when done.

---

Option 5: Add a local user via the REST API (as admin)

Once you're in via ZMI or failsafe_login, you can create a proper local Plone user with a password via the REST API or the Users control panel, so you have a persistent dev login without needing e.g. GitHub.

NOTE: acsr: These Options need a review!

Advanced methods

You can go even further when you are in control of the server as an admin, to regain access to the content via the frontends.

TBAL

[davisagli]

I skimmed this quickly; it looks accurate and I agree it would be good to add this to the documentation.

I would leave out option 4. I don't see that it has any advantage over option 1 and it temporarily breaks the authentication that non-admins are using.