Allow remove of banner, avatar images issue #353 v2 #2423

Closed
shpuld wants to merge 33 commits from gitlab-mr-iid-1156 into develop
Owner

Branched off the original MR at #2146 to fix conflicts, pushing to remote too much effort.

Branched off the original MR at https://git.pleroma.social/pleroma/pleroma-fe/pulls/2146 to fix conflicts, pushing to remote too much effort.

Backend returns what?

Backend returns what?
Author
Owner

no clue, I'm still investigating and testing stuff from this branch

no clue, I'm still investigating and testing stuff from this branch
Author
Owner

image

this is what the request returns

![image](/attachments/35a6ed61-b401-427b-a201-9540ad02e629) this is what the request returns
Author
Owner

image

Changed the avatar reset button style to overlay the avatar, didn't do this for banner/background which don't have a different length button next to them, banner is also variable sized and background doesn't even have a preview.

![image](/attachments/30a79501-1dfc-458c-a742-85e1f27ccc80) Changed the avatar reset button style to overlay the avatar, didn't do this for banner/background which don't have a different length button next to them, banner is also variable sized and background doesn't even have a preview.
Author
Owner

yo git wtf

yo git wtf

what the heck

what the heck

Which endpoint is being called here?

Which endpoint is being called here?
Author
Owner
const AVATAR_PATCH_URL = '/api/v1/pleroma/accounts/update_avatar'
const BANNER_PATCH_URL = '/api/v1/pleroma/accounts/update_banner'
const BACKGROUND_PATCH_URL = '/api/v1/pleroma/accounts/update_background'
```javascript const AVATAR_PATCH_URL = '/api/v1/pleroma/accounts/update_avatar' const BANNER_PATCH_URL = '/api/v1/pleroma/accounts/update_banner' const BACKGROUND_PATCH_URL = '/api/v1/pleroma/accounts/update_background' ```
Author
Owner

still possible that the code in this MR is using it wrong and mangling the result, but I haven't yet investigated that far

still possible that the code in this MR is using it wrong and mangling the result, but I haven't yet investigated that far

I like the 'x' to remove it, but it does feel a bit strange that it's only here and not with all of them. Not a dealbreaker but i think having more or less identical 'reset' or 'clear' buttons is for all of them is better

I like the 'x' to remove it, but it does feel a bit strange that it's only here and not with all of them. Not a dealbreaker but i think having more or less identical 'reset' or 'clear' buttons is for all of them is better

I think all of these were added because of old GS compatibility reasons. You can actually remove all of these by just sending a null as an argument to the normal update_credentials endpoint.

I think all of these were added because of old GS compatibility reasons. You can actually remove all of these by just sending a `null` as an argument to the normal `update_credentials` endpoint.
Author
Owner

Ill try that

Ill try that
Author
Owner

if I want X for all, I'll need to change the styles a bit I think to make them match otherwise too, right now avatar setting looks quite different

if I want X for all, I'll need to change the styles a bit I think to make them match otherwise too, right now avatar setting looks quite different
Author
Owner

Lies, invalid request

Lies, invalid request

i tested it just now, what are you testing against?

i tested it just now, what are you testing against?
Author
Owner

dontbulling.me

dontbulling.me
Author
Owner

which method should it use? updateCredentials is using PATCH for actually setting a new one. I tried with both avatar and banner, both return 403 with message "Invalid request". I don't see anything obviously wrong in the request

image

which method should it use? updateCredentials is using PATCH for actually setting a new one. I tried with both avatar and banner, both return 403 with message "Invalid request". I don't see anything obviously wrong in the request ![image](/attachments/14c9a623-4c51-4ae0-b98f-40b6dc21105a)

same as for setting a new one. just a hunch, but can you try sending the payload as json instead of form?

same as for setting a new one. just a hunch, but can you try sending the payload as json instead of form?
Author
Owner

I think the masto docs explicitly say to use forms

I think the masto docs explicitly say to use forms

try json. Source: dude trust me

try json. Source: dude trust me
Author
Owner

because going against the spec is always the way to go, fix the BE parts anyway no matter how we do it (t. not booting up the dev pc to change the code right now

because going against the spec is always the way to go, fix the BE parts anyway no matter how we do it (t. not booting up the dev pc to change the code right now

don't worry, i'll check what the actual issue is :)

don't worry, i'll check what the actual issue is :)

also maybe a stupid question, but did you send the authorization header?

also maybe a stupid question, but did you send the authorization header?

(sidenote: both form data and json should work and be equivalent, see https://docs.joinmastodon.org/client/intro/)

(sidenote: both form data and json should work and be equivalent, see https://docs.joinmastodon.org/client/intro/)
Author
Owner

yeah I'm pretty sure I checked that the header was there, I made it use the same function calls that successfully set the avatar too. those wouldn't work without auth right?

yeah I'm pretty sure I checked that the header was there, I made it use the same function calls that successfully set the avatar too. those wouldn't work without auth right?
Author
Owner

I can try it with json too I guess when I get back to it tomorrow

I can try it with json too I guess when I get back to it tomorrow

it shouldn't respond 403 if the auth is missing, i'll take a look at the backend again tomorrow. I did write tests for these exact cases yesterday, but as knuth said, i only proved it to be correct and didn't run it.

it shouldn't respond 403 if the auth is missing, i'll take a look at the backend again tomorrow. I did write tests for these exact cases yesterday, but as knuth said, i only proved it to be correct and didn't run it.
Author
Owner

if it wasn't providing the auth then there's something very strange going on with the FE code and should probably refactor things w

if it wasn't providing the auth then there's something very strange going on with the FE code and should probably refactor things w
Author
Owner

double checked, authorization header is being given when I get the 403

double checked, authorization header is being given when I get the 403
Author
Owner

tried the json trick, it sure returned 200 with params 'header': null, but the banner wasn't reset, not even after reloading...

tried the json trick, it sure returned 200 with params `'header': null`, but the banner wasn't reset, not even after reloading...

@_@

i'll check myself tomorrow, thanks for trying!

@_@ i'll check myself tomorrow, thanks for trying!
Author
Owner

not sure if it matters, but read the masto docs more closely, it says whenever uploading files you should use multipart/form-data, now the real question is, if you send null where it should be a file, is it ok to use json 🤔

not sure if it matters, but read the masto docs more closely, it says whenever uploading files you should use multipart/form-data, now the real question is, if you send null where it should be a file, is it ok to use json :thinking:
Author
Owner

adjusted things:

  • added background preview
  • scaled down the previews of banner and background
  • made the reset button the transparent X on all 3
  • removed the "your current avatar" stuff which was as useful as labels in political cartoons

image

adjusted things: - added background preview - scaled down the previews of banner and background - made the reset button the transparent X on all 3 - removed the "your current avatar" stuff which was as useful as labels in political cartoons ![image](/attachments/9927e66e-c326-49bc-b5bf-132c958cdf02)
318 KiB
Author
Owner

DOES NOT WORK until the null-setting for update_credentials is figured out and fixed

DOES NOT WORK until the null-setting for update_credentials is figured out and fixed

checked it now, indeed my test to check that this works was wrong, going into it again...

checked it now, indeed my test to check that this works was wrong, going into it again...

So here's what I found:

  • Resetting the images in the update_credentials call does not work, we filter nil-values out in multiple places
  • The test I wrote to confirm that this works was wrong, so I was under the wrong impression that it worked
  • It doesn't work in mastodon either, it returns a 'bad request'
  • Please use the specific reset endpoints again like you did originally
  • Sorry for the back-and-forth ;_;
So here's what I found: - Resetting the images in the update_credentials call does not work, we filter nil-values out in multiple places - The test I wrote to confirm that this works was wrong, so I was under the wrong impression that it worked - It doesn't work in mastodon either, it returns a 'bad request' - Please use the specific reset endpoints again like you did originally - Sorry for the back-and-forth ;_;
Author
Owner

🔫

:gun:
Author
Owner

how does mastodon reset avatar/header or does it do it at all?

how does mastodon reset avatar/header or does it do it at all?

They do it in the non-api parts of mastodon, in the backend-generated html settings page

They do it in the non-api parts of mastodon, in the backend-generated html settings page
Owner

POST https://mastodon.social/settings/profile/pictures/header

form data:
"_method":"delete",
"authenticity_token":"tenshieatingacorndog"

and it's a page navigation, not an XHR

POST https://mastodon.social/settings/profile/pictures/header form data: "_method":"delete", "authenticity_token":"tenshieatingacorndog" and it's a page navigation, not an XHR
Owner
        this.submitBackground(null)

otherwise it errors out

```suggestion:-0+0 this.submitBackground(null) ``` otherwise it errors out
Owner

code-wise looks ok, but currently doesn't work.

code-wise looks ok, but currently doesn't work.
Author
Owner
https://git.pleroma.social/pleroma/pleroma/-/issues/1918
Author
Owner

discussed it elsewhere and thought it's probably not a good idea to start using and locking in the ugly custom endpoints for this, but it'd be better to have a less broken way to do things. issue about it here https://git.pleroma.social/pleroma/pleroma/-/issues/1918

discussed it elsewhere and thought it's probably not a good idea to start using and locking in the ugly custom endpoints for this, but it'd be better to have a less broken way to do things. issue about it here https://git.pleroma.social/pleroma/pleroma/-/issues/1918
Author
Owner

ok, I have changed the code to work with pleroma/pleroma#6107 when it gets merged

ok, I have changed the code to work with https://git.pleroma.social/pleroma/pleroma/pulls/6107 when it gets merged
Author
Owner

this now works against latest develop

this now works against latest develop

🎉

:tada:

Pull request closed

Sign in to join this conversation.
No reviewers
No milestone
No project
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!2423
No description provided.