Bug: "Failed to validate AccessToken, please re-check your token or backend URL"

[paulcalabro]

Describe the bug Receiving the following error message when logging in using a Personal Access Token:

Failed to validate AccessToken, please re-check your token or backend URL

To Reproduce Steps to reproduce the behavior:

1. Go to "Credentials" -> "Add Credential"
2. Fill in URL, select "User Personal Access Token"
3. Enter access token
4. See error

Expected behavior Arrive at landing page

Screenshots N/A

Smartphone (please complete the following information):

• Device: iPhone 11
• OS: iOS 17.4
• Version 0.12.4

Additional context N/A

[paulcalabro]

https://github.com/victorbalssa/abacus/blob/8e1ca674ddff9b29cae74b841058a2243a411f10/src/components/Screens/CredentialCreateScreen.tsx#L91

[victorbalssa]

Hey @paulcalabro,

Was PAT working before 0.12.4? can you retry with a new PAT again?

I'm also trying to narrow down the login issues others can have (#257): Can you try to connect to this demo instance: https://demo.firefly-iii.org/ ? it will help me determine if it's really Abacus 0.12.4 with some iPhone configurations.

Do you use the latest FireflyIII version? (6.1.9)

Last thing, if you have access to an android, (if you can you replicate the same error on android)?

Thanks

[paulcalabro]

Hey @victorbalssa,

Here's the answers to your questions

• It was working before 0.12.4.
• IIRC, I could only use PAT because I use Authelia.
• I tried several times with a new PAT and it did not work.
• I tested and was able to log into https://demo.firefly-iii.org/ with a new PAT.
• Yep, I'm on 6.1.9.
• Unfortunately, I don't have an Android phone to test with.

I set up Burp Suite to act as a Proxy in between my phone and Firefly III. I noticed if I clicked on "Create a new Personal Access token on OAuth tab, here: <URL>" I saw traffic to the proxy. If I clicked on "Log in" (same URL, with a PAT), I saw no traffic to the proxy. If I used an IP address and a NC listener, I saw traffic.

[victorbalssa]

Thank you @paulcalabro, it will help me a lot, I suspect the last build to block some specific LAN traffic on IOS. I will replicate it on a raspberry pi, and keep you posted.

[paulcalabro]

@victorbalssa

You're welcome!

Given I could send traffic to a netcat listener (e.g. 192.168.68.123 on port 1234") and see traffic, I don't think it's necessarily blocking LAN traffic.

e.g.

• Spin up a NC listener:

  $ docker run -p 1234:1234 -it --rm alpine /bin/sh -c "nc -l -p 1234"

• Click the "Login" button.
• Review traffic at listener or in Burp Suite:

  GET /api/v1/about/user HTTP/1.1
  Host: 192.168.68.123:1234
  Connection: keep-alive
  Accept: application/json, text/plain, */*
  User-Agent: Abacus/0.12.4 CFNetwork/1494.0.6 Darwin/23.4.0
  Accept-Language: en-US,en;q=0.9
  Authorization: Bearer fake123
  Accept-Encoding: gzip, deflate

Initially, I was thinking what was happening and what could explain for the difference in behavior is name resolution:

• Scenario 1: 192.168.68.123 as a server requires no DNS lookup
• Scenario 2: my-server.home.arpa is resolved locally using a local DNS resolver (e.g. Pi-hole)
• Scenario 3: demo.firefly-iii.org is resolved recursively using upstream DNS resolvers (e.g. 8.8.8.8)

As I started to examining the DNS logs on my Pi-hole, I noticed something interesting: I couldn't see DNS queries being made for HTTP traffic:

Maybe something expects TLS and is silently failing?

[paulcalabro]

@victorbalssa

Okay, I was able to resolve my issue! 🥳 It looks like it is related to TLS.

For those experiencing the same issue, the tl;dr is I created a local CA, created a cert issued by that CA, and deployed the CA cert to my phone and computer. I then configured Traefik to use the cert issued by the CA.

Helpful resources:

• https://gist.github.com/fntlnz/cf14feb5a46b2eda428e000157447309?permalink_comment_id=3063255#file-self-signed-certificate-with-custom-ca-md
• https://support.apple.com/en-us/103769
• https://support.apple.com/en-us/102390

Sample v3.ext:

extendedKeyUsage = serverAuth
subjectAltName   = DNS:<FQDN>

Things that the first link doesn't cover OTB:

• the required SAN
• the ExtendedKeyUsage extension
• make sure the validity period is 825 days or fewer

So I think what's broken is the ability to NOT use TLS.

[victorbalssa]

This makes a lot more sense to me! 🎉

I will create a new version with the ability to use TLS AND unsecured http,

Thanks again @paulcalabro 💯

[victorbalssa]

Done in 0.13.2. Let me know if there is still an issue with this.