Internal Server Error of /oauth/authorized_applications #21885
Comments
|
The account used when this phenomenon occurred was created in April 2017. |
|
Thanks for the report! Could you run the following in a Rails console ( Account.find_local!('yourusername').user.applications.map { |app| app.scopes }.filter do |scopes|
scopes.map { |scope| ScopeParser.new.parse(scope) }
false
rescue
true
end |
|
|
Hm, strange, what about: Account.find_local!('SubwayTooter').user.applications.map { |app| app.scopes }.filter do |scopes|
scopes.map { |scope| ScopeTransformer.new.apply(ScopeParser.new.parse(scope)) }
false
rescue
true
end |
Doorkeeper.config.application_model.authorized_for(Account.find_local!('SubwayTooter').user).map { |app| app.scopes }.filter do |scopes|
scopes.map { |scope| ScopeTransformer.new.apply(ScopeParser.new.parse(scope)) }
false
rescue
true
end |
|
Doorkeeper.config.application_model.authorized_for(Account.find_local!('SubwayTooter').user).filter do |app|
app.scopes.map { |scope| ScopeTransformer.new.apply(ScopeParser.new.parse(scope)) }
false
rescue
true
end(scrub the secrets if needed) |
|
|
Oh, it looks like I specified it wrong when I tried oauth. |
|
ok this appears to be a very old app record with broken scopes, we would need to make sure it's not currently possible to register such apps, and to handle any existing one gracefully I guess |
|
FWIW I also have this issue; I'll look back upthread and see if I can fix my app too. |
|
Mine is not an old app; I ran the script you provided and got a much newer app: irb(main):014:1* Doorkeeper.config.application_model.authorized_for(Account.find_local!('offby1').user).filter do |app|
irb(main):015:1* app.scopes.map { |scope| ScopeTransformer.new.apply(ScopeParser.new.parse(scope)) }
irb(main):016:1* false
irb(main):017:1* rescue
irb(main):018:1* true
irb(main):019:0> end
=>
[#<Doorkeeper::Application:0x00007efd9d26b6e0
name: "autoadmin",
uid: "*** scrubbed ***",
secret: "*** scrubbed ****",
redirect_uri: "urn:ietf:wg:oauth:2.0:oob",
scopes:
"read write follow admin:read admin:read:accounts admin:read:canonical_email_blocks admin:read:domain_allows admin:read:domain_blocks admin:read:email_domain_blocks admin:read:ip_blocks admin:read:reports admin:write admin:write:accounts admin:write:canonical_email_blocks admin:write:domain_allows admin:write:domain_blocks admin:write:email_domain_blocks admin:write:ip_blocks admin:write:reports",
created_at: Mon, 24 Apr 2023 20:27:45.107234000 UTC +00:00,
updated_at: Mon, 24 Apr 2023 20:27:45.107234000 UTC +00:00,
superapp: false,
website: "",
owner_type: "User",
id: 8999,
owner_id: 1151,
confidential: true>]I'm gonna delete it -- it was an experiment I was running to see if I could set up an automated admin tool -- but I figured I'd record the scopes here for posterity. |
|
What error did you get? |
|
|
Thanks! 4.1.0 introduced scopes with underscores, but our parser does not handle that. Going to fix the issue! |
|
I have a user who registered in 2017 who is unable to visit this page I believe the user actually wants to delete the application, should it be ok to manually delete it so that they can visit the page again? |
|
I can't reproduce the issue, are you sure this is caused by an app with |
|
Thanks for taking a look @ClearlyClaire. Here's the stack trace: There is only one row in The user described that they have signed up to use several third party applications with the Mastodon instance, but every time they need to login they need to reconfirm their decision to trust the application, as if Mastodon had forgotten it (which is suggested by the presence of only a single row). Could it be some issue with the user settings? |
Ah! You're not looking into the right thing! Those are the applications created by the user, not those used by the user (that would thus appear on the page with an error). You'd want something like: SELECT "oauth_applications".id, "oauth_applications".scopes FROM "oauth_applications" WHERE "oauth_applications"."id" IN (SELECT DISTINCT "oauth_access_tokens"."application_id" FROM "oauth_access_tokens" WHERE "oauth_access_tokens"."resource_owner_id" = 435 AND "oauth_access_tokens"."revoked_at" IS NULL) |
|
Thank you! I wonder if it's the comma separated one? |
Yes, most likely. It shouldn't be possible to create such app records anymore, but this existing record is most definitely what's causing the issue. |
|
Updating that row fixed the problem. Thanks! I guess this issue can be closed? |
|
It should not be possible to create new apps with invalid scopes, so the issue should be mostly addressed, but old records can still be around and we probably need to either automatically clean them or at least prevent them from making the app list view crash. |
|
@ClearlyClaire The creation side is solved by using We probably want a migration to repair or delete old applications that aren't correct, though this could be complex to implement correctly |
Steps to reproduce the problem
but it's account dependent. please see detailed description
Expected behaviour
WebUI shows app list.
Actual behaviour
WebUI shows error page.
Detailed description
Specifications
Mastodon v4.0.2
using included Dockerfile
The text was updated successfully, but these errors were encountered: