Authenticating with Confluence

The following authentication methods are currently supported:

• Interactive authentication (note: this also covers anonymous access)
• Token-based authentication (Confluence 7.9 and later support the use of personal access tokens, and Confluence Cloud)

Interactive Authentication

With this authentication method WikiTraccs uses the context of a logged-in user account. It also covers anonymous access.

Read more: Interactive Authentication

Token-based Authentication

Note: this option is available as of WikiTraccs v1.13 and works with Confluence 7.9 and later, and Confluence Cloud.

Read more: Token-based Authentication

Required permissions in Confluence

The permissions of the Confluence account you log in with determine what can be migrated.

The easiest approach is to log in with a Confluence admin account that has access to all spaces that should be migrated. This allows for content and permission migration.

But maybe you don’t want to use a Confluence admin account. In this case you can also use an account that is space admin in all to-be-migrated spaces. This allows for content and permission migration of those spaces.

The least permissive approach is to use an account that is no admin whatsoever but has normal user permissions like view and edit. This allows for migration of content this account has access to, which might not be all pages. Permission migration is not possible with a non-admin user account.

Certain operations like retrieving user account information or group memberships might be prohibited for non-admin users which might hinder WikiTraccs. If you see such errors in the log try using an account that has more permissions.

Confluence Behind a Security Proxy

Some organizations route Confluence Cloud through a Cloud Access Security Broker (CASB) reverse proxy, like Microsoft Defender for Cloud Apps with Conditional Access App Control (“MCAS”). The sign: after login the address bar shows a rewritten host ending in .mcas.ms (e.g. your-site.atlassian.net.mcas.ms) plus a screen reading “Access to Atlassian is monitored … Access is only available from a web browser.” WikiTraccs then hangs at “Looking for a Confluence session” and reports “Could not get all required Confluence auth cookies”.

The proxy sits between you and Confluence: it rewrites the addresses and cookies (the session cookie even ends up encrypted on the .mcas.ms host) and restricts access to web browsers only. That can interfere with the different ways WikiTraccs connects to Confluence, so authentication may fail. This is your organization’s security configuration, not a WikiTraccs defect, which is why a working migration can stop the day the policy is switched on.

The clean fix is on the Microsoft 365 / Entra side: ask your security team to exclude the Atlassian apps (or just the migration account) from the Defender for Cloud Apps session policy and the Conditional Access “Use Conditional Access App Control” grant for the migration. “Monitor only” / “Report-only” is not enough: monitor mode still proxies, so a proper exclusion is required.

If exclusion is not possible, try token-based authentication instead: it uses a Confluence API token rather than a browser cookie, so it does not depend on the proxied session (though your security team may still need to allow that traffic). Microsoft Edge is sometimes exempt from the proxy and can help, depending on the configuration.