Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mastodon integration is forgotten instantly #2700

Open
tastytea opened this issue Jun 23, 2024 · 6 comments
Open

mastodon integration is forgotten instantly #2700

tastytea opened this issue Jun 23, 2024 · 6 comments
Labels
bug Something isn't working

Comments

@tastytea
Copy link

Describe the bug

i can add a mastodon API connection, it looks like it succeeded, the access token is visible on my instance.

but träwelling instantly forgets it exists and shows it as not connected. it worked up until recently, i think the last time i used it was 2-3 weeks ago?

i'm using sharkey 2024.3.3

Steps to reproduce

  1. go to https://traewelling.de/settings/security/login-providers
  2. connect to sharkey instance
  3. try to post a new status
  4. look at https://traewelling.de/settings/security/login-providers again to see that the integration is disconnected

Browser console logs

No response

Browser

firefox 127.0.1

@tastytea tastytea added the bug Something isn't working label Jun 23, 2024
@MrKrisKrisu
Copy link
Member

We currently only support "real" mastodon connections.
See #2560

@CutestNekoAqua
Copy link

We currently only support "real" mastodon connections. See #2560

This seems to be a different issue and it seems to be resulting in your commit from 3 weeks ago. Having the same issue on akkoma. Seems to be a issue with Traewelling requesting things out of scope I think?
I wrote the original Calckey Mastodon API and tested it against traewelling. Removing connections just because some instances return a 401 error that aren't official Mastodon instances doesn't seem like the right approach.

Additionally, all random instance errors while fetching an instance are being classified as "not a Mastodon instance," which gives the impression that all internal Traewelling errors on the API side are being labeled with an "official Mastodon only" policy.

There's a small difference between supporting Mastodon and supporting the Mastodon API. As a Mastodon-compatible software developer, I'd suggest focusing on supporting the API rather than just the official Mastodon instances. Otherwise, there is a risk of alienating a significant portion of users that would have loved the platform otherwise. That, I would not count as the spirit, FOSS software should life in.

@HerrLevin
Copy link
Member

HerrLevin commented Jul 7, 2024

I think the main problem is that we're currently using a library, that's tailored to mastodon itself and not the Mastodon API.

But I'm not entirely sure why removing accounts from an instance that returns a 401 is not adhering to the official documentation. As mentioned here, the instance returns a 401 when the API requires an authenticated user. Since we're requesting the account data with the credentials of the account itself, we have to assume, that our credentials for the API were revoked. (This is mostly a fallback for us because we had this exact situation, that some instances returned 401 and users couldn't recreate their API token, etc.)

Please let me know if the above mentioned API is not the one you meant or if I'm misinterpreting the documentation here. I'm fine with using only 404/410 for account removal, if that extends our compatibility.

@tastytea
Copy link
Author

tastytea commented Jul 8, 2024

i made a bug report to Sharkey: https://activitypub.software/TransFem-org/Sharkey/-/issues/574.

@CutestNekoAqua
Copy link

I think the main problem is that we're currently using a library, that's tailored to mastodon itself and not the Mastodon API.

But I'm not entirely sure why removing accounts from an instance that returns a 401 is not adhering to the official documentation. As mentioned here, the instance returns a 401 when the API requires an authenticated user. Since we're requesting the account data with the credentials of the account itself, we have to assume, that our credentials for the API were revoked. (This is mostly a fallback for us because we had this exact situation, that some instances returned 401 and users couldn't recreate their API token, etc.)

Please let me know if the above mentioned API is not the one you meant or if I'm misinterpreting the documentation here. I'm fine with using only 404/410 for account removal, if that extends our compatibility.

no in this case its a issue of "401 can be returned when there was a issue while making the request" which is different from "this api key i got is invalid". :)

@HerrLevin
Copy link
Member

no in this case its a issue of "401 can be returned when there was a issue while making the request" which is different from "this api key i got is invalid". :)

Can you point me to the location where the documentation states this behavior? I can't find it and this sounds more like 400 to me. 🫣

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants