[Bug] WikiTraccs crashes connecting to Confluence Cloud

[wahoo32]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Created appsettings.json and cookies.txt per instructions. Application crashes after retrieving tenants according to logs

Final 2 lines in logs:
[ 08:12:30 DBG] [https://xxxxxxxxxx.atlassian.net/wiki/] Start: Retrieving tenants for user xxxxxxxx... | WikiTraccs.Shared.ConfluenceInternal.ConfluenceInternalApiAccessor.ConfluenceGlobalApiAccessor
[ 08:12:30 DBG] [https://xxxxxxxxxx.atlassian.net/wiki/] Done: Retrieving tenants for user xxxxxxxx | WikiTraccs.Shared.ConfluenceInternal.ConfluenceInternalApiAccessor.ConfluenceGlobalApiAccessor

Expected Behavior

A successful connection to Confluence

WikiTraccs Version

v1.22.11

Confluence Version

Confluence Cloud

Confluence Data Center?

• This is about Confluence Data Center

Relevant log output or page storage format

No response

Anything else?

No response

[heinrich-ulbricht]

@wahoo32 Thanks for reporting and good catch. Quick question: why do you need to resort to cookies.txt, instead of using interactive authentication?

It seems that non-*.atlassian.net cookies are currently tripping up the cookie.txt parser of WikiTraccs.

A workaround seems to be to remove all cookies from cookies.txt that are for domains like .atlassian.com, .atl-paas.net etc. This makes the crash go away, but space retrieval seem to still fail.

The parser will be fixed in the next release of WikiTraccs.

[wahoo32]

Thank you for your prompt reply! Removing the Atlassian cookies does stop the crash, but does not find any sites to migrate: ***@***.*** The logged in Confluence user (me) that the cookies and appsettings.json are based on is a Confluence site admin. When I update the space inventory I get confirmation that no Confluence sites can be migrated. ***@***.*** I needed to resort to this method because the Interactive login always results in the following message ***@***.*** If this helps, the logs indicate a bad request: [ 10:52:10 INF] [Negotiate][#6][rest/api/user?username=doesnotmatter] Received non-success status code: BadRequest - Bad Request | When I run this API call through passman, I also get the same result [400 Bad Request]: { "statusCode": 400, "data": { "authorized": true, "valid": true, "errors": [], "successful": true }, "message": "com.atlassian.confluence.api.service.exceptions.BadRequestException: Username/Userkey are not accepted as parameters." } Thank you, ***@***.******@***.***>

[heinrich-ulbricht]

@wahoo32 Thanks for working with me on this.

I'm interested in what follows after "I needed to resort to this method because the Interactive login always results in the following message" - it looks like there should be an image but it didn't make it to this thread. Did you try Personal Token authentication as well? This could work if interactive fails.

Regarding the bad request you reported: you can ignore that. WikiTraccs is just probing different authentication methods.

The cookies.txt workaround was born from on-prem authentication problems as last resort and it seems those need some updates to be compatible with Confluence Cloud.

The appsettings.json config for Cloud slightly changed - please have a look at the now updated Provide Cookies manually docs, they show what to configure for Cloud; the parameter is called AjsRemoteAccountId.

In addition I found an issue with cookie values containing commas. (Side note: interesting discussion about the standard-conformity of that over there in the dotnet repo: dotnet/runtime#58773.)

The next WikiTraccs prerelease will contain the following adjustments:

• handle non atlassian.net cookies well
• don't stumble over cookie values with comma

The release is due this week.

[wahoo32]

Heinrich

The answer to 'I'm interested in what follows after "I needed to resort to this method because the Interactive login always results in the following message"' is the image showed "Failure Could not get all required Confluence auth cookies. Check advanced configuration, and make sure no leftover automated browsers are open. Then try again."

I tried personal token and I get the "Could not get authenticated data context for Confluence; I can do nothing." failure. I entered my token generated through Atlassian Cloud while logged into my administrator account.

As of this message I was only able to migrate a couple of spaces with anonymous access. The Confluence we are migrating has over 250 spaces and we will need to consider the risks and effort to convert them to anonymous access unless we can resolve this issue.

Thanks,

Wayne Hohler

[heinrich-ulbricht]

@wahoo32 Could you please test the latest prerelease? This makes cookies.txt compatible with Confluence Cloud. Please also note the documentation is now hinting at cookie value length limitations - something that I found happening while testing in Confluence Cloud.

Yet another workaround for authentication issues is the proxy mode, reserved for the really hard cases.

[wahoo32]

Heinrich, I downloaded the latest prerelease. While the app handles cookies.txt better, the Bad Requests are still resulting in no sites being found in Confluence when trying to use Interactive or Personal Token.

Proxy mode throws the "Cannot update Space Inventory. Chrome driver does not support IJavaScriptExecutor interface." error.

As mentioned, only anonymous access is working and while I can present this as an option it is doubtful the business will accept the risk.

[heinrich-ulbricht]

@wahoo32 All in all I consider this a "very strange" case. I get those about once a year and usually there is something to learn from those.

Going forward, if you are still willing to work with me on this, I see the following things we can do:

First: could you try migrating on another machine? Maybe one that is less bound to corporate restrictions? The IJavaScriptExecutor error makes me suspicious about things being blocked or old on the migration machine. So changing something in the environment - migration machine, target Confluence Cloud site, etc. might make a difference. I also had one case in the past where running WikiTraccs as administrator (with elevated privileges; "Right click -> Run as administrator") helped, although that shouldn't be necessary. But in that specific case it helped.

Second: please send me as many common log files as you got, showing the unsuccessful authentication attempts; often, I can see from the complete log what's going on; send them to [email protected] - of course only, if that is an option for you. At least one updated log for the most recent WikiTraccs release and cookie.txt test would be extremely helpful.

Third, and maybe most productive: I'd like to have a look at your system; would you be open to scheduling a ~30 minute screenshare session next week, where I can have a look at the system? Please let me know your time zone and availability via [email protected] - I'll send a Teams invite. Again, only if that is an option for you.

Thank you.