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

Revert "Merge branch 'oauth-extra-scopes' into 'develop'" #2299

Closed
lambadalambda wants to merge 0 commits from gitlab-mr-iid-1032 into develop
pull from: gitlab-mr-iid-1032
merge into: pleroma:develop
Conversation 11 Commits - Files changed -
lambadalambda commented 2019-12-12 09:38:30 +00:00
Owner
Copy link

This reverts merge request #2291

This reverts merge request #2291
i1t commented 2019-12-12 13:18:45 +00:00
Member
Copy link

@lambadalambda Once pleroma/pleroma#5439 is merged, it's safe to revert this revertion.

@lambadalambda Once https://git.pleroma.social/pleroma/pleroma/pulls/5439 is merged, it's safe to revert this revertion.
hj commented 2019-12-12 13:22:25 +00:00
Owner
Copy link

so it does NOT work on older backends, huh?

so it does NOT work on older backends, huh?
i1t commented 2019-12-12 13:24:16 +00:00
Member
Copy link

@hj It does work on back-ends older than 2 days (prior to merge of pleroma/pleroma#5403). And it'll work on new BEs once pleroma/pleroma#5439 is merged. Older BEs didn't reject admin scopes, they didn't make any use of them. New BEs make use of admin scopes, but we need to gracefully clear such for non-admin users.

Upd.: 2061 was merged.

@hj It _does_ work on back-ends older than 2 days (prior to merge of https://git.pleroma.social/pleroma/pleroma/pulls/5403). And it'll work on new BEs once https://git.pleroma.social/pleroma/pleroma/pulls/5439 is merged. Older BEs didn't reject admin scopes, they didn't make any use of them. New BEs make use of admin scopes, but we need to gracefully clear such for non-admin users. Upd.: 2061 was merged.
hj commented 2019-12-12 13:40:54 +00:00
Owner
Copy link

so if i understand correctly either a DB migration adds missing scopes automatically or FE needs to request those itself? What was the reason for original revert?

so if i understand correctly either a DB migration adds missing scopes automatically or FE needs to request those itself? What was the reason for original revert?
rinpatch commented 2019-12-12 13:44:23 +00:00
Member
Copy link

What was the reason for original revert?

If you requested admin scope as a non-admin user on a backend that support admin scopes, it would reject the request.

So if i understand correctly either a DB migration adds missing scopes automatically or FE needs to request those itself?

Currently it's the latter, though I think we should do the former. @i1t what do you think?

> What was the reason for original revert? If you requested `admin` scope as a non-admin user on a backend that support admin scopes, it would reject the request. > So if i understand correctly either a DB migration adds missing scopes automatically or FE needs to request those itself? Currently it's the latter, though I think we should do the former. @i1t what do you think?
hj commented 2019-12-12 13:47:39 +00:00
Owner
Copy link

If you requested admin scope as a non-admin user on a backend that support admin scopes, it would reject the request.

That sounds... weird. How do you ask for admin scope when logging in as admin or as a regular user? Ask backend if user is an admin sounds weird.

>If you requested `admin` scope as a non-admin user on a backend that support admin scopes, it would reject the request. That sounds... weird. How do you ask for admin scope when logging in as admin or as a regular user? Ask backend if user is an admin sounds weird.
i1t commented 2019-12-12 14:32:31 +00:00
Member
Copy link

PleromaFE creates an app on each load and sets supported OAuth scopes on it. It used to be read write follow, now it's read write follow push admin.

On sign-in, PleromaFE requests OAuth scopes for the user. At this stage it's unknown whether a user is an admin or not, and it'd be incorrect to pre-request this info anyways. So, PleromaFE requests read write follow push admin for any user. BE determines if user is an admin and keeps admin scopes(s) only in this case, so the resulting token has read write follow push admin scopes for admins and read write follow push for non-admins.

If new version of FE interacts with older BE, it'll result in read write follow push admin scopes set for all users. Older BEs don't deal with admin scopes (i.e. grant no special abilities if those are present) and don't control usage of those.

@rinpatch, once we bundle updated FE versions with BE, I agree it'd be better to migrate existing apps / admin authorizations / admin tokens to add admin scope. Will take care of that once admin scope functionality is merged to PleromaFE again.

PleromaFE creates an app on each load and sets supported OAuth scopes on it. It used to be `read write follow`, now it's `read write follow push admin`. On sign-in, PleromaFE requests OAuth scopes for the user. At this stage it's unknown whether a user is an admin or not, and it'd be incorrect to pre-request this info anyways. So, PleromaFE requests `read write follow push admin` for any user. BE determines if user is an admin and keeps admin scopes(s) only in this case, so the resulting token has `read write follow push admin` scopes for admins and `read write follow push` for non-admins. If new version of FE interacts with older BE, it'll result in `read write follow push admin` scopes set for all users. Older BEs don't deal with admin scopes (i.e. grant no special abilities if those are present) and don't control usage of those. @rinpatch, once we bundle updated FE versions with BE, I agree it'd be better to migrate existing apps / admin authorizations / admin tokens to add `admin` scope. Will take care of that once admin scope functionality is merged to PleromaFE again.
i1t commented 2019-12-12 14:46:04 +00:00
Member
Copy link

Created the revert of this revert: #2301

Created the revert of this revert: https://git.pleroma.social/pleroma/pleroma-fe/pulls/2301
hj commented 2019-12-12 15:18:56 +00:00
Owner
Copy link

IIRC it should not create an app on each new load, it tries to reuse existing one stored in browser's storage.

Another thing to consider: what will happen if you make some user an admin/moderator?

Also what push scope does?

IIRC it should not create an app on each new load, it tries to reuse existing one stored in browser's storage. Another thing to consider: what will happen if you make some user an admin/moderator? Also what `push` scope does?
i1t commented 2019-12-12 16:39:49 +00:00
Member
Copy link

@hj, push is a standard Mastodon scope for managing push subscriptions. Added a more detailed description to #2301.

As for making someone an admin, it doesn't currently modify this user's tokens. Some apps (unfortunately, not all) allow user to explicitly select OAuth permissions on sign in, and it could be that an admin user intentionally deselected admin scopes in some client apps, so we shouldn't extend token scopes for every app. As for PleromaFE, we know that it (currently) doesn't allow users to deselect any scopes, so we could potentially extend PleromaFE (and bundled MastoFE, though there were good times it allowed to specifically select permissions on login) tokens with admin scope when user is made an admin.

When an admin is downgraded to a regular user, such user is signed out of all apps. We could do the same when user is promoted to an admin from regular user, that'd be easier and more transparent (plus no need to make guesses on why any permissions that app supports are missing on token, was it a user decision or not).

@hj, `push` is a standard Mastodon scope for managing push subscriptions. Added a more detailed description to https://git.pleroma.social/pleroma/pleroma-fe/pulls/2301. As for making someone an admin, it doesn't currently modify this user's tokens. Some apps (unfortunately, not all) allow user to explicitly select OAuth permissions on sign in, and it could be that an admin user intentionally deselected admin scopes in some client apps, so we shouldn't extend token scopes for every app. As for PleromaFE, we know that it (currently) doesn't allow users to deselect any scopes, so we could potentially extend PleromaFE (and bundled MastoFE, though there were good times it allowed to specifically select permissions on login) tokens with admin scope when user is made an admin. When an admin is downgraded to a regular user, such user is signed out of all apps. We could do the same when user is promoted to an admin from regular user, that'd be easier and more transparent (plus no need to make guesses on why any permissions that app supports are missing on token, was it a user decision or not).
i1t commented 2019-12-14 07:06:48 +00:00
Member
Copy link

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). #2301 is ready for the merge.

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). https://git.pleroma.social/pleroma/pleroma-fe/pulls/2301 is ready for the merge.

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
4 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!2299
No description provided.