pleroma/pleroma-fe
0
0
Fork 0
Code Issues 343 Pull requests 27 Projects Releases Packages Wiki Activity

Reinstate push and admin scopes #2301

Closed
i1t wants to merge 0 commits from gitlab-mr-iid-1034 into develop
pull from: gitlab-mr-iid-1034
merge into: pleroma:develop
Conversation 6 Commits - Files changed -
i1t commented 2019-12-12 14:44:46 +00:00
Member
Copy link

Reinstate push and admin scopes (temporarily reverted until the BE fix which is now merged: pleroma/pleroma#5439).

See #2299

Note: right now BE does not enforce admin scopes usage, and FE will work with older and new versions of BE without the need to do anything to tokens (e.g. sign out / sign in isn't needed).

NB. As for the push scope, it controls accessibility of push subscriptions API endpoints, see https://git.pleroma.social/pleroma/pleroma/blob/develop/lib/pleroma/web/mastodon_api/controllers/subscription_controller.ex.

Reinstate `push` and `admin` scopes (temporarily reverted until the BE fix which is now merged: https://git.pleroma.social/pleroma/pleroma/pulls/5439). See https://git.pleroma.social/pleroma/pleroma-fe/pulls/2299#note_48084 Note: right now BE does not enforce admin scopes usage, and FE will work with older and new versions of BE without the need to do anything to tokens (e.g. sign out / sign in isn't needed). NB. As for the `push` scope, it controls accessibility of push subscriptions API endpoints, see https://git.pleroma.social/pleroma/pleroma/blob/develop/lib/pleroma/web/mastodon_api/controllers/subscription_controller.ex.
i1t commented 2019-12-14 07:06:06 +00:00
Author
Member
Copy link

@rinpatch @lambadalambda, could you please merge this MR?

@rinpatch @lambadalambda, could you please merge this MR?
hj commented 2019-12-14 12:40:05 +00:00
Owner
Copy link

i still don't understand how "user became an admin" case would be handled

i still don't understand how "user became an admin" case would be handled
rinpatch commented 2019-12-14 13:12:30 +00:00
Member
Copy link

We probably could store permissions requested by the app, and if the user becomes an admin, we search through tokens and update the ones that requested this permission. This sounds counter-intuitive though, I would rather just tell the user to get a new token

We probably could store permissions requested by the app, and if the user becomes an admin, we search through tokens and update the ones that requested this permission. This sounds counter-intuitive though, I would rather just tell the user to get a new token
hj commented 2019-12-14 13:26:41 +00:00
Owner
Copy link

two things in my mind about it:

  1. Make a migration that updates scopes for ALL PleromaFE apps to also include push and admin since PleromaFE doesn't exactly let you select scopes when logging in.
  2. "tell the user to get a new token" sounds bad. My approach would be granting all scopes that are requested, i.e. giving a non-admin an "admin" scope but not giving them admin privileges.

The idea of ability to define scopes, as I understand it, is to safeguard certain applications from doing something they shouldn't be doing, i.e. you wouldn't want some 3rd party python bot suddenly banning other people because you tested it on your own account or something.

You don't revoke "read" and "write" permissions if user is banned, don't you? I don't see why admin permission should be tied to admin status.

two things in my mind about it: 1. Make a migration that updates scopes for ALL PleromaFE apps to also include push and admin since PleromaFE doesn't exactly let you select scopes when logging in. 2. "tell the user to get a new token" sounds bad. My approach would be granting all scopes that are requested, i.e. giving a non-admin an "admin" scope but not giving them admin privileges. The idea of ability to define scopes, as I understand it, is to safeguard certain applications from doing something they shouldn't be doing, i.e. you wouldn't want some 3rd party python bot suddenly banning other people because you tested it on your own account or something. You don't revoke "read" and "write" permissions if user is banned, don't you? I don't see why admin permission should be tied to admin status.
i1t commented 2019-12-14 13:45:55 +00:00
Author
Member
Copy link

First of all, until this MR is merged, it doesn't make any sense to add any PleromaFE apps / authorizations / tokens migrations to BE (since the migrations would be run once, and after that bundled PleromaFE would still request "read write follow").

After this MR is merged, I'll prepare BE MR involving PleromaFE update and, possibly, migration of existing Pleroma apps / authorizations / tokens (though I'd say once a token is issued it shouldn't be modified [given clients may cache it etc.], it should be revoked if we need to modify it). I propose to discuss migration specifics in BE MR.

As for this specific MR, it's totally compatible with older and newer BE releases, and PleromaFE is going to request admin scope for sure. The changes in this MR are proper ones, there doesn't seem to be any alternatives. We could have alternatives on BE implementation, yes, but not on FE side in this case.

First of all, until this MR is merged, it doesn't make any sense to add any PleromaFE apps / authorizations / tokens migrations to BE (since the migrations would be run once, and after that bundled PleromaFE would still request "read write follow"). After this MR is merged, I'll prepare BE MR involving PleromaFE update and, possibly, migration of existing Pleroma apps / authorizations / tokens (though I'd say once a token is issued it shouldn't be modified [given clients may cache it etc.], it should be revoked if we need to modify it). I propose to discuss migration specifics in BE MR. As for this specific MR, it's totally compatible with older and newer BE releases, and PleromaFE _is_ going to request `admin` scope for sure. The changes in this MR are proper ones, there doesn't seem to be any alternatives. We could have alternatives on BE implementation, yes, but not on FE side in this case.
i1t commented 2019-12-14 14:01:09 +00:00
Author
Member
Copy link

I propose to merge this MR and continue the discussion in pleroma/pleroma#1478.

I propose to merge this MR and continue the discussion in https://git.pleroma.social/pleroma/pleroma/issues/1478.

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
BE Request

   
Backlog

   
Better behavior

   
Blocked by deps

   
Bug

   
Code Review

   
Discussion

   
Doing

   
Feature Request / Enhancement

   
In the shining bright future maybe

   
It's complicated

   
MS Edge

   
Mememoon (or other niche browsers)

   
Missing API

   
Missing feature

   
Missing l10n/i18n

   
NL1

Instance Admin Dashboard

  
NL2

Improved Mobile Experience

  
NL4

Improved instance customization and QoL options

  
Need to verify on develop

   
RELEASE BLOCKER

   
Reassign or Close

   
Refactor

   
Regression

   
Safari

   
To Do

   
User story

   
Waiting on godot

   
accessibility

https://git.pleroma.social/pleroma/pleroma-fe/-/snippets/7746

  
better documentation

   
chore

   
confirmed

   
easy ticket

   
incident

Denotes a disruption to IT services and the associated issues require immediate attention

  
l10n update

   
mastoapi

   
mobile

   
needs design

   
needs-info

   
needs-review

   
stupid
No labels
BE Request
Backlog
Better behavior
Blocked by deps
Bug
Code Review
Discussion
Doing
Feature Request / Enhancement
In the shining bright future maybe
It's complicated
MS Edge
Mememoon (or other niche browsers)
Missing API
Missing feature
Missing l10n/i18n
NL1
NL2
NL4
Need to verify on develop
RELEASE BLOCKER
Reassign or Close
Refactor
Regression
Safari
To Do
User story
Waiting on godot
accessibility
better documentation
chore
confirmed
easy ticket
incident
l10n update
mastoapi
mobile
needs design
needs-info
needs-review
stupid
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pleroma/pleroma-fe!2301
No description provided.