Can’t sign in (and worsening issues)

paulrobertlloyd commented 10 months ago

Last week:

I was previously using the v3.1 iOS app via TestFlight (iPhone 11 Pro, iOS 16.6). Thinking I should revert back to the ‘production’ version of the app, I uninstalled it, and redownloaded the app from the App Store.
Opened the app downloaded from the App Store.
After signing in, I got an unstyled web view saying I wasn’t signed in on each view I tried to load (there was a brief mention of no token being provided before it was replaced with this message). I tried signing in both with my email address, and an app token. Neither worked.

Today:

v3.2 was made available in TestFlight, so I downloaded this version hoping it might address the above issue.
Opened the app download from TestFlight, and still wasn’t able to sign in.
Went to Settings > General > iPhone Storage > Micro.blog and selected ‘Delete App’, thinking there might be some data conflict or a cached file causing mischief.
Redownloaded v3.2 app from TestFlight.
Now the app crashes instantly after trying to open it.

Probably a variety of issues working against each other here, but basically neither v3.1 (App Store) or v3.2 (TestFlight) versions of the app work for me right now.

vincentritter commented 10 months ago

Thanks for reporting. Will investigate.

vincentritter commented 10 months ago

I've made a few tweaks to the way the app now launches.

What I think has happened is that, somehow, the Token data is persisted even when you uninstall the app – which makes sense as it's stored in the Keychain – and this directly affecting other stored states in cache.

iOS should also, at the same time, clear any stored data (not in the keychain) when you uninstall the app, however I have a feeling it doesn't do this. Totally understand you have also "cleared" this data from iOS settings as per your issue.

Whilst I cannot reproduce this issue, there are a few things the app is now checking BEFORE the app fully launches, which might cause some old, or conflicting, data to crash the app. Whilst the crash is not reproducible at the moment, I believe the way it loads up the app now, should hopefully give you a clear state of the app the next time you open it.

This will ship in the next iOS beta and I will let you know when it's ready to test.

I need to make a few more tweaks to this just to handle some other edge cases, for example when there is "Auth" data, but no Token data – if so, it should do the same as above and give you a clear state.

paulrobertlloyd commented 10 months ago

Thanks for tracking down these issues, hopefully they address the above. Looking forward to testing the next beta!

vincentritter commented 10 months ago

During the dev session today, I had the un-styled "you are not signed in" message you mentioned.

That issue occurred because the Auth model state is storing if the web view has previously loaded. On initial load of the app (from clean install), this is always set to false – that means it will use a sign in URL before showing the timeline. Once loaded the web views will change that state to true.

The problem here is, that state is saved, so the next time the app loads it will see that the web view has already loaded, and will avoid going through the sign in step.

That combined with clearing cookies on app launches means that the session is lost with the server, resulting in that message.

Now it will set the did_load_one_or_more_webviews to false once the Auth model has hydrated causing it to use the sign in URL again, and also get a new session cookie from the server.

vincentritter commented 9 months ago

@paulrobertlloyd – could you please give the latest build/iOS TestFlight a go and let me know if your issues are fixed?

paulrobertlloyd commented 9 months ago

I posted 2 screenshots via TestFlight's feedback mechanism yesterday.

In short, app no longer crashes, and the errors are better handled, but sadly the same issue persists; it won't let me log in, complaining about invalid tokens. Even if I create a new app token, it rejects it ☹️

vincentritter commented 9 months ago

Thank you Paul! Shame it's still not letting you in. Using an app token should work, so I am unsure what's happening...

I will do a few more tests with tokens this coming week.

Would you be conformable sharing your token to help@micro.blog for testing purpose? You can create a special one-off and revoke it after testing. If not, that's fine... I might work with Manton on this to see if something is wrong on the server side of things on the account.

vincentritter commented 9 months ago

Hey @paulrobertlloyd, I've looked into this more, and I believe I may have a solution for this (again). However note that I can't reproduce the exact error as you describe.

My thinking here is, that when the App checks for existing Token data, your account is certainly there, but there might be a conflict of which token the app provides back to the User model.

There are two commits now that should resolve this (I hope).

I believe this bug was introduced when we added the ability to log into third-party sites via IndieAuth where token data is separated by a type of token. We store a type of user and service. When the app gets back the token data for the actual User it didn't include the type check, so it might just be the case that you tried to add a third-party site previously, with perhaps the same username, which is stored as service and the app was using this to try and authenticate because it was the first one it found.

I do believe this should fix what you're seeing, although again I am stabbing in the dark a little.

Next up I added an extra check when you encounter the token error message as per your screenshot. When the app presents you with the error, it will go through the logout flow where it removes the stored User data – just like before – with an additional step of clearing all stored Token data if no other users exist in the app. That should help clear out any old data.

Hoping to get this fix out today or next week, and I'll let you know.

vincentritter commented 9 months ago

Hey @paulrobertlloyd, that's available as a TestFlight now (build 301). We're actually releasing this in the App Store on Monday. However, I am happy to keep investigating this if it continues to be an issue.

paulrobertlloyd commented 9 months ago

I'm in! That must have been the issue, then. Thanks for taking the time to track it down 🤗

paulrobertlloyd commented 2 months ago

Not sure when this started happening again, and maybe the old issue never really went away…

If I sign in with the URL https://indiekit-sandbox.netlify.app, I can complete the auth flow, sign in and post.
If I try to sign in with the URL https://paulrobertlloyd.com, I get the following 3 warnings, layered upon each other:
1. Sorry, we could not find the XML-RPC endpoint or Micropub API for your weblog
2. An error occurred trying to connect. Please try again
3. Whoops, an error occurred trying to connect. Please try again

Having failed to get the iOS app running on my machine, I abstracted out the discover_micropub_endpoints function and gave it both URLs, and it was able to correctly find the corresponding endpoints:

sandbox: {
  micropub: 'https://indiekit.up.railway.app/micropub',
  auth: 'https://indiekit.up.railway.app/auth',
  token: 'https://indiekit.up.railway.app/auth/token',
  is_wordpress: false
}

paulrobertlloyd: {
  micropub: 'https://kit.paulrobertlloyd.com/micropub',
  auth: 'https://kit.paulrobertlloyd.com/auth',
  token: 'https://kit.paulrobertlloyd.com/auth/token',
  is_wordpress: false
}

There should be no difference in behaviour, as both sites use the same rel <link>s, and point to the same version of the same Micropub server software.

I wonder if the token storage is still an issue? I uninstalled the app etc., but this made no difference.

microdotblog / microblog-react

Can’t sign in (and worsening issues) #60