The table that is affected here was not properly purged of old entries. It only holds
data that is needed while a 3rd party authorization is in progress but not finished.
The code that typeorm generated for this migration is a bit wonky because it should
probably have dropped one column and created another one. But if we clear out all entries
it should work regardless and I'm feeling lazy right now. :P
This also simplifies API authentication a bit by not having to fetch
the App that is related to a token.
The restriction of 1 token per app is also lifted. This was not a
constraint in the database but it was enforced by the code and
kinda wrong schema the auth_session table had.
This setting is unnecessary because DeepL free keys can be detected
easily according to <https://www.deepl.com/docs-api/api-access/authentication/>:
> DeepL API Free authentication keys can be identified easily by the suffix ":fx"
Changelog: Removed
The thing that previously presumably hindered this was that the VAPID
keys had to be set up. Previously admins had to do this, but this is a bad
idea for multiple reasons:
1) The meaning of "public key" and "private key" was not well documented
in the settings.
2) Giving out a private key over the API, even just for admins, sounds
like a bad idea.
Co-authored-by: Francis Dinh <normandy@biribiri.dev>
Also remove the contributors list from about-foundkey (renamed from
about-misskey).
Some comments that referenced Misskey were also translated to English.
Closes: FoundKeyGang/FoundKey#141
GNU Social's follow request IDs are larger than the 128 character limit
of the follow_request.requestId column. This prevents follow requests
from GNU Social instances from being handled by Foundkey instances.
The solution is to make the requestId column larger.
Fixes FoundKeyGang/FoundKey#146
The column mentionedRemoteUsers on the note table in the database is
firstly in the wrong type since it contains JSON data but is typed as
text. Secondly it seems redundant, since that data can be acquired by
using the note.mentions column to fetch the respective data instead.
Co-authored-by: Francis Dinh <normandy@biribiri.dev>
This API endpoint is not working correctly and can cause unintended data loss:
It may remove emojis that have been imported from other instances.
See also https://github.com/misskey-dev/misskey/issues/8222
Instead of putting the URL in the report text, it is stored separately
so that users do not accidentally change or remove it.
This way it can easily be used when forwarding reports to different
instances to tell them what exactly was reported.
These two URLs are static so there is no reason to keep them in the
database. They are also not even used anywhere by the API, so they can
also be removed from there.
Where they are used is in the nodeinfo, where they are now hardcoded.
While editing the nodeinfo, also uncommented nodeinfo version 2.1.
* enhance: make theme color format uniform
All newly fetched instance theme colors will be uniformely formatted
as hashtag followed by 6 hexadecimal digits.
Colors are checked for validity and invalid colors are not handled.
* better input validation for own theme color
* migration to unify theme color formats
Fixes theme colors of other instances as well as the local instance.
* add changelog entry
Co-authored-by: syuilo <Syuilotan@yahoo.co.jp>
* chore: remove default null
null is always the default value if a table column is nullable, and typeorm's
@Column only accepts strings for default.
* chore: synchronize code with database schema
* chore: sync generated migrations with code
* fix: handle regex exceptions for word mutes
* add i18n strings
Co-authored-by: rinsuki <428rinsuki+git@gmail.com>
* stricter input validation in backend
* add migration for hard mutes
* fix
* use correct regex library in migration
* use query builder to avoid SQL injection
Co-authored-by: Robin B <robflop98@outlook.com>
Co-authored-by: rinsuki <428rinsuki+git@gmail.com>