-
-
Notifications
You must be signed in to change notification settings - Fork 7.1k
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
Add more granular OAuth scopes #7929
Conversation
c835fed
to
487b5e9
Compare
487b5e9
to
77d8f87
Compare
I agree on the scopes, but not the design. We should group scopes by “privacy” level. Read public profile, Read Public toots, Etc. it should be grouped by what people do. If I use an app, yes, I want to know they can do each thing, but I also what that high level overview. A list like this isn’t useful to non technical users. We must make that simple for people to understand. What does each thing mean? Maybe displau it grouped by topic?
|
That is, it should be grouped by type, not access level; they’re different vertices. |
So, basically, you need to transpose this into a grid: field / read / write For the top levels, they should just auto-check all below. Check all / read, abd it checks everything below it in read |
The current design is too developer focused; from a user perspective I want to know who and what can do what things. |
@ThisIsMissEm The screenshot is from the development "create app" UI. The authorize page is untouched, and simply lists the human description of the requested scopes as before. |
I'm hoping it's an incremental improvement and will allow for more improvements on top of it in the future. Most importantly there is still no way to get different statuses depending on scope, it's all or nothing. |
@Gargron okay, so, I’d take things that are generic (read/write/follow) and put those in a separate section, to discourage their use; I think “push” could also be split up into finer grain items, but it isn’t critical for now. Then the remainder can be groups by object like shown above, rather than a flat list. Currently the list looks overwhelming and jumbled, but by adding grouping we can make it much clearer for developers & help encourage them to make better choices |
Maybe I could assign color codes to each scope, and the top-level ones could be dangerous red or something, additionally to re-grouping them. Personally I don't know if client apps should get the top-level or all of the specific ones. What if a new feature comes out, like filters? Then all apps would have to re-register and re-authenticate their users... I'm probably not going to add anything more to this PR though, because 37 changed files is on the high end of what I expect other contributors to read and review. |
I think even for client apps people should know exactly what that application is going to be able to access on their behalf. It's not like we can create an access token that'll only work on the device — nothing stops apps from exfiltrating access tokens to remote servers to scrap data and collect information breaching user privacy.
… On 3 Jul 2018, at 4:25 pm, Eugen Rochko ***@***.***> wrote:
Maybe I could assign color codes to each scope, and the top-level ones could be dangerous red or something, additionally to re-grouping them. Personally I don't know if client apps should get the top-level or all of the specific ones. What if a new feature comes out, like filters? Then all apps would have to re-register and re-authenticate their users...
I'm probably not going to add anything more to this PR though, because 37 changed files is on the high end of what I expect other contributors to read and review.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#7929 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB4ay2sH4F8XYrKykEgivLmTPd_2b_Cks5uC37qgaJpZM4U_09B>.
|
e13748a
to
474e709
Compare
@@ -1,7 +1,7 @@ | |||
# frozen_string_literal: true | |||
|
|||
class Api::V1::FollowsController < Api::BaseController | |||
before_action -> { doorkeeper_authorize! :follow } | |||
before_action -> { doorkeeper_authorize! :follow, :'write:follows', :'write:follows:create' } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the :'write:follows:create'
intentional? Is there a third tier too?
@@ -1,8 +1,8 @@ | |||
# frozen_string_literal: true | |||
|
|||
class Api::V1::ListsController < Api::BaseController | |||
before_action -> { doorkeeper_authorize! :read }, only: [:index, :show] | |||
before_action -> { doorkeeper_authorize! :write }, except: [:index, :show] | |||
before_action -> { doorkeeper_authorize! :read, :'read:lists' }, only: [:index, :show] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously the colons were aligned too (there are a few others like this)
:'write:notifications', | ||
:'write:reports', | ||
:'write:statuses', | ||
:read, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to be added to optional_scopes
too?
|
||
before do | ||
user.account.block_domain!('example.com') | ||
allow(controller).to receive(:doorkeeper_token) { token } | ||
end | ||
|
||
shared_examples 'forbidden for wrong scope' do |wrong_scope| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say this should be moved to some shared place once other controller specs use it too (blocks and accounts already have the same though)
* Add more granular OAuth scopes * Add human-readable descriptions of the new scopes * Ensure new scopes look good on the app UI * Add tests * Group scopes in screen and color-code dangerous ones * Fix wrong extra scope
this is the most clear documentation of the API scopes I could found: mastodon/mastodon#7929
Fix #7121
PUT /api/v1/accounts/verify_credentials
POST /api/v1/statuses/:id/pin
POST /api/v1/statuses/:id/unpin
POST /api/v1/accounts/:id/block
POST /api/v1/accounts/:id/unblock
POST|DELETE /api/v1/domain_blocks
POST /api/v1/statuses/:id/favourite
POST /api/v1/statuses/:id/unfavourite
POST /api/v1/filters
PUT|DELETE /api/v1/filters/:id
POST /api/v1/accounts/:id/follow
POST /api/v1/accounts/:id/unfollow
POST /api/v1/follows
POST /api/v1/follow_requests/:id/authorize
POST /api/v1/follow_requests/:id/reject
POST|DELETE /api/v1/lists/:id/accounts
POST /api/v1/lists
PUT|DELETE /api/v1/lists/:id
POST /api/v1/media
PUT /api/v1/media/:id
POST /api/v1/statuses/:id/mute
POST /api/v1/statuses/:id/unmute
POST /api/v1/accounts/:id/mute
POST /api/v1/accounts/:id/unmute
POST /api/v1/notifications/clear
POST /api/v1/notifications/:id/dismiss
POST /api/v1/reports
POST /api/v1/statuses/:id/reblog
POST /api/v1/statuses/:id/unreblog
POST /api/v1/statuses
DELETE /api/v1/statuses/:id
GET /api/v1/accounts/verify_credentials
GET /api/v1/accounts/:id/followers
GET /api/v1/accounts/:id/following
GET /api/v1/accounts/search
GET /api/v1/statuses/:id/favourited_by
GET /api/v1/statuses/:id/reblogged_by
GET /api/v1/accounts/:id
GET /api/v1/blocks
GET /api/v1/domain_blocks
GET /api/v1/favourites
GET /api/v1/filters
GET /api/v1/filters/:id
GET /api/v1/accounts/relationships
GET /api/v1/follow_requests
GET /api/v1/accounts/:id/lists
GET /api/v1/lists/:id/accounts
GET /api/v1/lists
GET /api/v1/lists/:id
GET /api/v1/mutes
GET /api/v1/notifications
GET /api/v1/notifications/:id
GET /api/v1/reports
GET /api/v1/search
GET /api/v2/search
GET /api/v1/accounts/:id/statuses
GET /api/v1/timelines/direct
GET /api/v1/timelines/home
GET /api/v1/timelines/list/:id
GET /api/v1/statuses/:id
GET /api/v1/statuses/:id/context
GET /api/v1/statuses/:id/card
All UIs remain the same before, except the developer form for creating new apps, which I have adjusted: