The <link rel="mentioned" /> tag refers to accounts by href. So we were
matching the DB by the url attribute, and falling back to HTTP look-up.
However, GS and Mastodon use profile URLs as URIs, too, and the match
for that was missing. This could potentially alleviate some extra network
requests
Create MediaAttachment but without actual file download when domain is blocked with reject_media set to true
Clean up old media files when creating a new domain block with reject_media set to true
Return remote_url in media attachments API if local file is not present
Undo domain block action in admin UI
Ability to enable reject_media from admin UI
* User can create a custom.scss to customize their instance without modifying gitted files.
* Add documentation for customization.
* Forgot the helper file
* Fix Style to pass codeclimate
* Requests from maintainer.
An attempt to open a brand new Mastodon instance configured
as SINGLE_USER_MODE=true will cause an exception.
Enable temporary registration if we have no users in the database
Fixes#1817
* Add eslint-plugin-jsx-a11y.
* Fix npm script.
* Adjust npm scripts so test also runs lint.
* Fix existing lint errors.
* Don't break on a11y issues.
* Add role and tabIndex.
* Add vim and Mac files to .gitignore and .dockerignore.
* Handle htmlFor (partially), a that's actually a button.
* Fix missing tabIndex.
* Add cursor:pointer to load-more
* Revert change to load_more.
* Fixes based on review.
* Update yarn.lock.
* Don't try to install fsevents on Linux (hides warning noise).
* Add recovery code support for two-factor auth
When users enable two-factor auth, the app now generates ten
single-use recovery codes. Users are encouraged to print the codes
and store them in a safe place.
The two-factor prompt during login now accepts both OTP codes and
recovery codes.
The two-factor settings UI allows users to regenerated lost
recovery codes. Users who have set up two-factor auth prior to
this feature being added can use it to generate recovery codes
for the first time.
Fixes#563 and fixes#987
* Set OTP_SECRET in test enviroment
* add missing .html to view file names
* Begin coverage for account search service
* Coverage for hashtag query
* Coverage for calling local vs remote find based on domain presence
* Spec to check that exact matches are not duped
* Coverage of resolve option
* Coverage for account being provided
* Start to refactor account search service
* Isolate query username and domain methods
* Isolate exact_match method
* Extract methods for local and remote results
* Simplify local vs remote and account isoliation
* Extract methods for local and remote results
* Simplify de-dupe of exact match
* Simplify logic to check for non exact remotes
* Cache some methods
* Remove nil from exact_match from results array
* Return exact matches first
* Use find_remote even with no domain
Account.find_local is just an alias for Account.find_remote(user, nil) - so we
can not bother with the conditional here, and call find_remote directly.
* Refresh local info for remote accounts when webfinger returns new values
It only refreshes account info if one of the URLs or the public-key changes,
in which cases it refreshes the full info, re-downloading the feeds from that
user.
Some special handling should probably be done when the public key changes,
but I have been unable to find any use for it in Mastodon yet.
* Re-fetch remote users we aren't subscribed to.
This might induce performance issues, we might want to only do that for users
we explicitly attempted to subscribe but failed to.
* Refactor changes
* Do not refresh existing remote account details more than once a day
* Avoid re-fetching webfinger info in tests unless otherwise specified
* Working translation for Norwegian.
* Fixes to Norwegian translation.
* Further adjustments to Norwegian translation.
* Further adjustments to Norwegian translation.
* Yet more improvements to the Norwegian translation.
* More Norwegian translations. Better terminology.
* Allow running mastodon on a different domain as the one used for identifying users
* Alter documentation of WEB_DOMAIN to make clear it shouldn't be used unless the admin knows what they are doing
* Compare to web_domain instead of local_domain when dealing with feeds/API
* Correctly identify mentions to local accounts
Mentions URLs point to the person's web profile, i.e., the user page served on WEB_DOMAIN.
