CSDUMMI

At the moment, the archive files are stored in `FileField`s. Which appear to be stored on the local disk. https://github.com/bookwyrm-social/bookwyrm/blob/a4599d0374e2719b50d7d381ca61fbb8a6a3f4cb/bookwyrm/models/bookwyrm_export_job.py#L26C19-L26C28

I have not. It appears to fix the issue with third-party apps, but does not fix the SSO Login issue. My work-around for that later issue was introducing a novel...

Was the form action CSP policy introduced in response to any actual vulnerability in Mastodon?

I'm running a test setup on a fork of glitch-soc that I maintain [here](https://gitlab.com/babka_net/mastodon-babka). As an IdP I use [keycloak](https://keycloak.org). If you want, I can share the minimal docker-compose file...

When I clicked on the login button, the button caused a CSP violation due to the SSO provider not being included under the `form-action: 'self';` policy. I fixed this by...

I will do that.

Thank you. I rebased on glitch's current main and now it's working. I'll close this issue.

After researching this issue, we found that this issue might relate to an overwrite of the redirect location stored by `store_location_for(:user)`. Currently, when trying to authorize a third-party app, such...

What I believe happens: Between step 1 and 2, `store_location_for(:user, 'https://pinafore.social/settings/instances/add')` is called. Then upon step 3, `store_location_for(:user, '/auth/sign_in')` overwriting the previous value. Then upon step 6, `stored_location_for(:user)` is called...

The reason why I believe that store_location_for is called upon every redirect, is because of this function in devise: [`redirect`](https://github.com/heartcombo/devise/blob/main/lib/devise/failure_app.rb#L77)