Eugen Rochko [Thu, 28 Sep 2017 21:20:08 +0000 (23:20 +0200)]
Change max redirects followed to 2 (#5136)
I see no reason to allow more than that. Usually a redirect is
HTTP->HTTPS, then maybe URL structure changed, but more than that
is highly unlikely to be a legitimate use case.
Eugen Rochko [Thu, 28 Sep 2017 15:50:14 +0000 (17:50 +0200)]
If HTTP signature is wrong and webfinger cache is stale, retry with resolve (#5129)
If the signature could not be verified and the webfinger of the account
was last retrieved longer than the cache period, try re-resolving the
account and then attempting to verify the signature again
Eugen Rochko [Thu, 28 Sep 2017 13:31:31 +0000 (15:31 +0200)]
Add ability to specify alternative text for media attachments (#5123)
* Fix #117 - Add ability to specify alternative text for media attachments
- POST /api/v1/media accepts `description` straight away
- PUT /api/v1/media/:id to update `description` (only for unattached ones)
- Serialized as `name` of Document object in ActivityPub
- Uploads form adjusted for better performance and description input
Eugen Rochko [Wed, 27 Sep 2017 21:42:49 +0000 (23:42 +0200)]
When OAuth password verification fails, return 401 instead of redirect (#5111)
Call to warden.authenticate! in resource_owner_from_credentials would
make the request redirect to sign-in path, which is a bad response for
apps. Now bad credentials just return nil, which leads to HTTP 401
from Doorkeeper. Also, accounts with enabled 2FA cannot be logged into
this way.
Eugen Rochko [Mon, 25 Sep 2017 22:29:29 +0000 (00:29 +0200)]
Send streaming API delete to people mentioned in status (#5103)
- Previously they wouldn't receive it unless they were author's
followers
- Skip unpush from public/hashtag timelines if status wasn't
public in the first place
Eugen Rochko [Mon, 25 Sep 2017 21:05:54 +0000 (23:05 +0200)]
New error page graphic. Other error page improvements (#5099)
- 500.html generated with admin-set default locale if set
- Error page `<title>` includes Mastodon site title
- 500 title changed to "This page is not
correct" (ref: <https://www.youtube.com/watch?v=2VCAP_seh1A>)
- 500 content appended with "on our end" to make clear it's
not user's fault
Eugen Rochko [Mon, 25 Sep 2017 16:36:33 +0000 (18:36 +0200)]
Fix emojify() by generating a mapping to existing Twemoji files (#5080)
A new rake task emojis:generate downloads a full list of valid
unicode sequences from unicode.org and checks it against existing
Twemoji files, finally generating a map from each sequence to the
existing file (e.g. when there's multiple ways an emoji can be
expressed). The map is dumped into app/javascript/mastodon/emoji_map.json
That file is loaded by emojione_light.js (now a misnomer) which
decorates it further with shortcodes taken from emoji-mart's index.
We added horizontal layout to preview card for wide image. However, max height of the thumbnail is still limited to 120px and it makes nearly square images to too small for that layout.
This PR increases max height as well as max width.
Fix shortname problem in emojify() (regression from #5016) (#5032)
When colon appears end of line, skiped all character containing unicode emojis. Fixed.
https://github.com/tootsuite/mastodon/pull/5016#issuecomment-331012008
Use file extensions in addition to MIME types for file picker (#5029)
Currently we're using a list of MIME types for `accept` attribute on `input[type="file"]` for filter options of file picker, and actual file extensions will be infered by browsers. However, infered extensions may not include our expected items. For example, "image/jpeg" seems to be infered to
only ".jfif" extension in Firefox.
To ensure common file extensions are in the list, this PR adds file extensions in addition to MIME types. Also having items in both format is encouraged by HTML5 spec.
Change IDs to strings rather than numbers in API JSON output (#5019)
* Fix JavaScript interface with long IDs
Somewhat predictably, the JS interface handled IDs as numbers, which in
JS are IEEE double-precision floats. This loses some precision when
working with numbers as large as those generated by the new ID scheme,
so we instead handle them here as strings. This is relatively simple,
and doesn't appear to have caused any problems, but should definitely
be tested more thoroughly than the built-in tests. Several days of use
appear to support this working properly.
BREAKING CHANGE:
The major(!) change here is that IDs are now returned as strings by the
REST endpoints, rather than as integers. In practice, relatively few
changes were required to make the existing JS UI work with this change,
but it will likely hit API clients pretty hard: it's an entirely
different type to consume. (The one API client I tested, Tusky, handles
this with no problems, however.)
Twitter ran into this issue when introducing Snowflake IDs, and decided
to instead introduce an `id_str` field in JSON responses. I have opted
to *not* do that, and instead force all IDs to 64-bit integers
represented by strings in one go. (I believe Twitter exacerbated their
problem by rolling out the changes three times: once for statuses, once
for DMs, and once for user IDs, as well as by leaving an integer ID
value in JSON. As they said, "If you’re using the `id` field with JSON
in a Javascript-related language, there is a very high likelihood that
the integers will be silently munged by Javascript interpreters. In most
cases, this will result in behavior such as being unable to load or
delete a specific direct message, because the ID you're sending to the
API is different than the actual identifier associated with the
message." [1]) However, given that this is a significant change for API
users, alternatives or a transition time may be appropriate.
These should be the last two. These were identified using eslint to try
to identify any plain casts to JavaScript numbers. (Some such casts are
legitimate, but these were not.)
Adding the following to .eslintrc.yml will identify casts to numbers:
~~~
no-restricted-syntax:
- warn
- selector: UnaryExpression[operator='+'] > :not(Literal)
message: Avoid the use of unary +
- selector: CallExpression[callee.name='Number']
message: Casting with Number() may coerce string IDs to numbers
~~~
The remaining three casts appear legitimate: two casts to array indices,
one in a server to turn an environment variable into a number.
* Back out RelationshipsController Change
This was made to make a test a bit less flakey, but has nothing to
do with this branch.
* Change internal streaming payloads to stringified IDs as well
Per
https://github.com/tootsuite/mastodon/pull/5019#issuecomment-330736452
we need these changes to send deleted status IDs as strings, not
integers.
Eugen Rochko [Tue, 19 Sep 2017 00:42:40 +0000 (02:42 +0200)]
Custom emoji (#4988)
* Custom emoji
- In OStatus: `<link rel="emoji" name="coolcat" href="http://..." />`
- In ActivityPub: `{ type: "Emoji", name: ":coolcat:", href: "http://..." }`
- In REST API: Status object includes `emojis` array (`shortcode`, `url`)
- Domain blocks with reject media stop emojis
- Emoji file up to 50KB
- Web UI handles custom emojis
- Static pages render custom emojis as `<img />` tags
Side effects:
- Undo #4500 optimization, as I needed to modify it to restore
shortcode handling in emojify()
- Formatter#plaintext should now make sure stripped out line-breaks
and paragraphs are replaced with newlines
cat aescling's git repositories / mastodon.git / log