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.

For a complete content and permission migration, use an account that can:

• view every selected page, blog post, and attachment
• read the page restrictions for that content
• retrieve the required user and group information

A Confluence administrator or space administrator account is often the easiest choice. However, an administrative role does not automatically bypass every page restriction in every Confluence deployment. Confirm the account’s effective access to restricted content instead of relying on the role name alone.

A non-admin account can migrate content it can view. Permission migration with such an account is possible only when the account can also retrieve all required restriction, user, and group data. If that data is incomplete, use an account with broader access.

Selector behavior matters as well: CQL selectors can omit restricted pages, including pages an administrative account can otherwise open. See Known Issues and limitations for the complete permission migration limitations.

Confluence Behind a Security Proxy

Some organizations route Confluence 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.