#54213 closed defect (bug) (fixed)
"Authorize Application" should reject handling an already existing app name
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.7 | Priority: | normal |
Severity: | normal | Version: | 5.6 |
Component: | Application Passwords | Keywords: | needs-testing-info has-patch has-unit-tests |
Focuses: | Cc: |
Description
or give a better message than the current (5.8) "Each application name should be unique.".
Should probably point the user to its profile page with a message saying something like "if you want to get new password to use for *appname* you should first revoke the current one"
If the app name is not existing at all as a url parameter it should probably just display some error on the page which indicates that an appname is missing and the that it is probably bug in the application that sent the user to the URL.
Change History (11)
This ticket was mentioned in Slack in #core-test by hellofromtonya. View the logs.
3 years ago
#3
@
3 years ago
@Boniu91
- while logged in go to wp-admin/authorize-application.php. With this url there is not application name/id and therefor it should just be denied as in the admin side when adding application password you must specify an application name. A message like "an application must supply an application name, contact the application's author with this information" should be displayed to the user.
- On the admin side add an application password for an application "app". Now go to wp-admin/authorize-application.php?app_name=app. Even at this point any further steps should be denied as the application already exist, and the user should be directed to his his account to revoke the corrent password if it wants to reauthenticate the application.
In the current behaviour user clicks "Yes I approve..." only to get a very user hostile message that tells him what the code checks instead of telling him what steps he should take.
Now that I look at it while trying to add the same app twice on the admin side I see that the same message is used there, but from the context it is much easier to get what the problem is (although that message can probably be improved as well)
This ticket was mentioned in Slack in #core-test by boniu91. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-passwords by jeffpaul. View the logs.
5 months ago
This ticket was mentioned in PR #7391 on WordPress/wordpress-develop by @TimothyBlynJacobs.
5 months ago
#6
- Keywords has-patch has-unit-tests added
In [50030] we enforced that Application Passwords have unique names. This was done with the assumption that applications would not connect to a user multiple times. However, in practice we've seen applications run into issues with the unique name constraint. Depending on the app, they may not know if they've been authorized before, or they may intentionally allow connecting multiple times. To prevent friction, App developers need to make their App Name unique, and in doing so often include things like the current date & time, which is already included in the App Passwords list table.
This commit removes this requirement to simplify usage of the Authorize Application flow.
Props mark-k, Boniu91.
Fixes #54213.
Trac ticket: https://core.trac.wordpress.org/ticket/54213
#7
@
5 months ago
- Milestone changed from Awaiting Review to 6.7
- Owner set to TimothyBlynJacobs
- Status changed from new to accepted
@TimothyBlynJacobs commented on PR #7391:
5 months ago
#8
Thanks for the review! Yeah my thinking is that the date does that differentiation. It'll also remain correct even if a user revokes an application password, where the numbering might end up getting confusing?
@peterwilsoncc commented on PR #7391:
5 months ago
#9
Thanks for the review! Yeah my thinking is that the date does that differentiation.
Works for me, I'll leave you to do the commit honours. Thanks.
@TimothyBlynJacobs commented on PR #7391:
5 months ago
#11
Merged in r59084.
Hello @mark-k
Thanks for creating this ticket. While ago we made sure that application names should be unique:
https://core.trac.wordpress.org/ticket/51941
As a Test team we wanted to better understand and reproduce the problem on our end, could you provide us with exact steps that we need to perform in order to see the problem?
Thank you!