* Add REST API for creating an account
The method is available to apps with a token obtained via the client
credentials grant. It creates a user and account records, as well as
an access token for the app that initiated the request. The user is
unconfirmed, and an e-mail is sent as usual.
The method returns the access token, which the app should save for
later. The REST API is not available to users with unconfirmed
accounts, so the app must be smart to wait for the user to click a
link in their e-mail inbox.
The method is rate-limited by IP to 5 requests per 30 minutes.
* Redirect users back to app from confirmation if they were created with an app
* Add tests
* Return 403 on the method if registrations are not open
* Require agreement param to be true in the API when creating an account
Conflicts:
- app/controllers/admin/base_controller.rb
- app/controllers/filters_controller.rb
- app/controllers/invites_controller.rb
- app/controllers/settings/deletes_controller.rb
- app/controllers/settings/exports_controller.rb
- app/controllers/settings/follower_domains_controller.rb
- app/controllers/settings/migrations_controller.rb
- app/controllers/settings/notifications_controller.rb
- app/controllers/settings/preferences_controller.rb
- app/controllers/settings/two_factor_authentication/recovery_codes_controller.rb
- app/javascript/packs/public.js
- app/views/settings/profiles/show.html.haml
Conflicts were mostly due to the addition of body classes to the settings page,
this was caused by rejecting upstream changes for most of those files and
modifying Settings::BaseController instead.
Another cause of conflicts was the deletion of client-side checking of
display name / bio length, this was modified in app/javascript/core/settings.js
instead.
Right now, this includes three endpoints: host-meta, webfinger, and change-password.
host-meta and webfinger are publicly available and do not use any authentication. Nothing bad can be done by accessing them in a user's browser.
change-password being CORS-enabled will only reveal the URL it redirects to (which is /auth/edit) but not anything about the actual /auth/edit page, because it does not have CORS enabled.
The documentation for hosting an instance on a different domain should also be updated to point out that Access-Control-Allow-Origin: * should be set at a minimum for the /.well-known/host-meta redirect to allow browser-based non-proxied instance discovery.
Conflicts:
- .github/ISSUE_TEMPLATE/bug_report.md
Took our version.
- CONTRIBUTING.md
Updated the embedded copy of upstream's version.
- README.md
Took our version.
- app/policies/status_policy.rb
Not a real conflict, took code from both.
- app/views/layouts/embedded.html.haml
Added upstream's changes (dns-prefetch) and fixed
`%body.embed`
- app/views/settings/preferences/show.html.haml
Reverted some of upstream changes, as we have a
page dedicated for flavours and skins.
- config/initializers/content_security_policy.rb
Kept our version of the CSP.
- config/initializers/doorkeeper.rb
Not a real conflict, took code from both.
Conflicts:
db/migrate/20170716191202_add_hide_notifications_to_mute.rb
spec/controllers/application_controller_spec.rb
Took our version, upstream changes were only minor style linting.
* Verify link ownership with rel="me"
* Add explanation about verification to UI
* Perform link verifications
* Add click-to-copy widget for verification HTML
* Redesign edit profile page
* Redesign forms
* Improve responsive design of settings pages
* Restore landing page sign-up form
* Fix typo
* Support <link> tags, add spec
* Fix links not being verified on first discovery and passive updates
CSFR-prevention is already implemented but adding this doesn't hurt.
A brief introduction to Same-Site cookies (and the difference between strict and
lax) can be found at
https://blog.mozilla.org/security/2018/04/24/same-site-cookies-in-firefox-60/
TLDR: We use lax since we want the cookies to be sent when the user navigates
safely from an external site.
Conflicts:
app/views/layouts/application.html.haml
Edited:
app/helpers/application_helper.rb
app/views/admin/domain_blocks/new.html.haml
Conflict wasn't really one, just two changes too close to one another.
Edition was to adapt the class names for themes to class names for
skins and flavours.
Also edited app/views/admin/domain_blocks/new.html.haml to strip the
duplicate admin pack inclusion thing.
* Fix uncaching worker
* Revert to using Paperclip's filesystem backend instead of fog-local
fog-local has lots of concurrency issues, causing failure to delete files,
dangling file records, and spurious errors UncacheMediaWorker
Conflicts:
app/models/status.rb
db/migrate/20180528141303_fix_accounts_unique_index.rb
db/schema.rb
Resolved by taking upstream changes (no real conflicts, just glitch-soc
specific code too close to actual changes).
Adopted from GitLab CE. Generate new migration with:
rails g post_deployment_migration name_of_migration_here
By default they are run together with db:migrate. To not run them,
the env variable SKIP_POST_DEPLOYMENT_MIGRATIONS must be set
Code by Yorick Peterse <yorickpeterse@gmail.com>, see also:
83c8241160
Adopted from GitLab CE. Generate new migration with:
rails g post_deployment_migration name_of_migration_here
By default they are run together with db:migrate. To not run them,
the env variable SKIP_POST_DEPLOYMENT_MIGRATIONS must be set
Code by Yorick Peterse <yorickpeterse@gmail.com>, see also:
83c8241160
Conflicts:
README.md
app/controllers/statuses_controller.rb
app/lib/feed_manager.rb
config/navigation.rb
spec/lib/feed_manager_spec.rb
Conflicts were resolved by taking both versions for each change.
This means the two filter systems (glitch-soc's keyword mutes and tootsuite's
custom filters) are in place, which will be changed in a follow-up commit.
* 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
