2020-08-11 12:24:59 -04:00
// @ts-check
2023-05-23 11:15:17 -04:00
const fs = require ( 'fs' ) ;
const http = require ( 'http' ) ;
const url = require ( 'url' ) ;
2017-06-25 22:49:39 -04:00
const dotenv = require ( 'dotenv' ) ;
const express = require ( 'express' ) ;
2023-09-01 11:44:28 -04:00
const Redis = require ( 'ioredis' ) ;
2023-05-23 11:15:17 -04:00
const { JSDOM } = require ( 'jsdom' ) ;
const log = require ( 'npmlog' ) ;
2017-06-25 22:49:39 -04:00
const pg = require ( 'pg' ) ;
2023-03-03 15:01:18 -05:00
const dbUrlToConfig = require ( 'pg-connection-string' ) . parse ;
2023-08-04 10:11:30 -04:00
const metrics = require ( 'prom-client' ) ;
2017-06-25 22:49:39 -04:00
const uuid = require ( 'uuid' ) ;
2021-03-24 04:37:41 -04:00
const WebSocket = require ( 'ws' ) ;
2017-05-20 11:31:47 -04:00
2023-04-26 05:37:51 -04:00
const environment = process . env . NODE _ENV || 'development' ;
2017-02-02 10:11:36 -05:00
dotenv . config ( {
2023-04-26 05:37:51 -04:00
path : environment === 'production' ? '.env.production' : '.env' ,
2017-05-20 11:31:47 -04:00
} ) ;
2017-02-01 19:31:09 -05:00
2017-05-28 10:25:26 -04:00
log . level = process . env . LOG _LEVEL || 'verbose' ;
2020-08-11 12:24:59 -04:00
/ * *
2023-09-01 11:44:28 -04:00
* @ param { Object . < string , any > } config
2020-08-11 12:24:59 -04:00
* /
2023-09-01 11:44:28 -04:00
const createRedisClient = async ( config ) => {
const { redisParams , redisUrl } = config ;
const client = new Redis ( redisUrl , redisParams ) ;
2021-12-25 16:55:06 -05:00
client . on ( 'error' , ( err ) => log . error ( 'Redis Client Error!' , err ) ) ;
2017-05-20 15:06:09 -04:00
2021-12-25 16:55:06 -05:00
return client ;
2017-05-20 15:06:09 -04:00
} ;
2020-09-22 09:30:41 -04:00
/ * *
2023-06-09 13:29:16 -04:00
* Attempts to safely parse a string as JSON , used when both receiving a message
* from redis and when receiving a message from a client over a websocket
* connection , this is why it accepts a ` req ` argument .
2020-09-22 09:30:41 -04:00
* @ param { string } json
2023-06-09 13:29:16 -04:00
* @ param { any ? } req
2023-04-29 20:29:54 -04:00
* @ returns { Object . < string , any > | null }
2020-09-22 09:30:41 -04:00
* /
2022-02-16 08:37:26 -05:00
const parseJSON = ( json , req ) => {
2020-09-22 09:30:41 -04:00
try {
return JSON . parse ( json ) ;
} catch ( err ) {
2023-06-09 13:29:16 -04:00
/ * F I X M E : T h i s l o g g i n g i s n ' t g r e a t , a n d s h o u l d p r o b a b l y b e d o n e a t t h e
* call - site of parseJSON , not in the method , but this would require changing
* the signature of parseJSON to return something akin to a Result type :
* [ Error | null , null | Object < string , any } ] , and then handling the error
* scenarios .
* /
if ( req ) {
if ( req . accountId ) {
log . warn ( req . requestId , ` Error parsing message from user ${ req . accountId } : ${ err } ` ) ;
} else {
log . silly ( req . requestId , ` Error parsing message from ${ req . remoteAddress } : ${ err } ` ) ;
}
2022-02-16 08:37:26 -05:00
} else {
2023-06-09 13:29:16 -04:00
log . warn ( ` Error parsing message from redis: ${ err } ` ) ;
2022-02-16 08:37:26 -05:00
}
2020-09-22 09:30:41 -04:00
return null ;
}
} ;
2023-03-04 19:52:12 -05:00
/ * *
2023-04-26 05:37:51 -04:00
* @ param { Object . < string , any > } env the ` process.env ` value to read configuration from
2023-04-29 20:29:54 -04:00
* @ returns { Object . < string , any > } the configuration for the PostgreSQL connection
2023-03-04 19:52:12 -05:00
* /
2023-04-26 05:37:51 -04:00
const pgConfigFromEnv = ( env ) => {
2017-04-16 22:32:30 -04:00
const pgConfigs = {
development : {
2023-04-26 05:37:51 -04:00
user : env . DB _USER || pg . defaults . user ,
password : env . DB _PASS || pg . defaults . password ,
database : env . DB _NAME || 'mastodon_development' ,
host : env . DB _HOST || pg . defaults . host ,
port : env . DB _PORT || pg . defaults . port ,
2017-04-16 22:32:30 -04:00
} ,
production : {
2023-04-26 05:37:51 -04:00
user : env . DB _USER || 'mastodon' ,
password : env . DB _PASS || '' ,
database : env . DB _NAME || 'mastodon_production' ,
host : env . DB _HOST || 'localhost' ,
port : env . DB _PORT || 5432 ,
2017-05-20 11:31:47 -04:00
} ,
} ;
2017-02-01 19:31:09 -05:00
2023-03-04 19:52:12 -05:00
let baseConfig ;
2020-08-11 12:24:59 -04:00
2023-04-26 05:37:51 -04:00
if ( env . DATABASE _URL ) {
baseConfig = dbUrlToConfig ( env . DATABASE _URL ) ;
2023-08-18 09:05:35 -04:00
// Support overriding the database password in the connection URL
if ( ! baseConfig . password && env . DB _PASS ) {
baseConfig . password = env . DB _PASS ;
}
2023-03-04 19:52:12 -05:00
} else {
2023-04-26 05:37:51 -04:00
baseConfig = pgConfigs [ environment ] ;
2023-03-04 19:52:12 -05:00
2023-04-26 05:37:51 -04:00
if ( env . DB _SSLMODE ) {
switch ( env . DB _SSLMODE ) {
2023-03-04 19:52:12 -05:00
case 'disable' :
case '' :
baseConfig . ssl = false ;
break ;
case 'no-verify' :
baseConfig . ssl = { rejectUnauthorized : false } ;
break ;
default :
baseConfig . ssl = { } ;
break ;
}
}
}
2017-12-12 09:13:24 -05:00
2023-03-04 19:52:12 -05:00
return {
... baseConfig ,
2023-04-26 05:37:51 -04:00
max : env . DB _POOL || 10 ,
2023-02-09 05:20:59 -05:00
connectionTimeoutMillis : 15000 ,
2023-03-04 19:52:12 -05:00
application _name : '' ,
} ;
} ;
2023-04-26 05:37:51 -04:00
/ * *
* @ param { Object . < string , any > } env the ` process.env ` value to read configuration from
2023-04-29 20:29:54 -04:00
* @ returns { Object . < string , any > } configuration for the Redis connection
2023-04-26 05:37:51 -04:00
* /
const redisConfigFromEnv = ( env ) => {
2023-09-01 11:44:28 -04:00
// ioredis *can* transparently add prefixes for us, but it doesn't *in some cases*,
// which means we can't use it. But this is something that should be looked into.
const redisPrefix = env . REDIS _NAMESPACE ? ` ${ env . REDIS _NAMESPACE } : ` : '' ;
2017-02-07 08:37:12 -05:00
2017-05-07 13:42:32 -04:00
const redisParams = {
2023-09-01 11:44:28 -04:00
host : env . REDIS _HOST || '127.0.0.1' ,
port : env . REDIS _PORT || 6379 ,
db : env . REDIS _DB || 0 ,
2023-04-26 05:37:51 -04:00
password : env . REDIS _PASSWORD || undefined ,
2017-05-20 11:31:47 -04:00
} ;
2017-05-07 13:42:32 -04:00
2023-09-01 11:44:28 -04:00
// redisParams.path takes precedence over host and port.
if ( env . REDIS _URL && env . REDIS _URL . startsWith ( 'unix://' ) ) {
redisParams . path = env . REDIS _URL . slice ( 7 ) ;
2017-05-07 13:42:32 -04:00
}
2017-05-20 15:06:09 -04:00
2023-04-26 05:37:51 -04:00
return {
redisParams ,
redisPrefix ,
redisUrl : env . REDIS _URL ,
} ;
} ;
const startServer = async ( ) => {
const app = express ( ) ;
app . set ( 'trust proxy' , process . env . TRUSTED _PROXY _IP ? process . env . TRUSTED _PROXY _IP . split ( /(?:\s*,\s*|\s+)/ ) : 'loopback,uniquelocal' ) ;
const pgPool = new pg . Pool ( pgConfigFromEnv ( process . env ) ) ;
const server = http . createServer ( app ) ;
2022-03-21 14:08:29 -04:00
/ * *
2023-06-09 13:29:16 -04:00
* @ type { Object . < string , Array . < function ( Object < string , any > ) : void >> }
2022-03-21 14:08:29 -04:00
* /
const subs = { } ;
2023-09-01 11:44:28 -04:00
const redisConfig = redisConfigFromEnv ( process . env ) ;
const redisSubscribeClient = await createRedisClient ( redisConfig ) ;
const redisClient = await createRedisClient ( redisConfig ) ;
const { redisPrefix } = redisConfig ;
2017-02-07 08:37:12 -05:00
2023-08-04 10:11:30 -04:00
// Collect metrics from Node.js
metrics . collectDefaultMetrics ( ) ;
new metrics . Gauge ( {
name : 'pg_pool_total_connections' ,
help : 'The total number of clients existing within the pool' ,
collect ( ) {
this . set ( pgPool . totalCount ) ;
} ,
} ) ;
new metrics . Gauge ( {
name : 'pg_pool_idle_connections' ,
help : 'The number of clients which are not checked out but are currently idle in the pool' ,
collect ( ) {
this . set ( pgPool . idleCount ) ;
} ,
} ) ;
new metrics . Gauge ( {
name : 'pg_pool_waiting_queries' ,
help : 'The number of queued requests waiting on a client when all clients are checked out' ,
collect ( ) {
this . set ( pgPool . waitingCount ) ;
} ,
} ) ;
const connectedClients = new metrics . Gauge ( {
name : 'connected_clients' ,
help : 'The number of clients connected to the streaming server' ,
labelNames : [ 'type' ] ,
} ) ;
connectedClients . set ( { type : 'websocket' } , 0 ) ;
connectedClients . set ( { type : 'eventsource' } , 0 ) ;
const connectedChannels = new metrics . Gauge ( {
name : 'connected_channels' ,
help : 'The number of channels the streaming server is streaming to' ,
labelNames : [ 'type' , 'channel' ]
} ) ;
const redisSubscriptions = new metrics . Gauge ( {
name : 'redis_subscriptions' ,
help : 'The number of Redis channels the streaming server is subscribed to' ,
} ) ;
// When checking metrics in the browser, the favicon is requested this
// prevents the request from falling through to the API Router, which would
// error for this endpoint:
app . get ( '/favicon.ico' , ( req , res ) => res . status ( 404 ) . end ( ) ) ;
app . get ( '/api/v1/streaming/health' , ( req , res ) => {
res . writeHead ( 200 , { 'Content-Type' : 'text/plain' } ) ;
res . end ( 'OK' ) ;
} ) ;
app . get ( '/metrics' , async ( req , res ) => {
try {
res . set ( 'Content-Type' , metrics . register . contentType ) ;
res . end ( await metrics . register . metrics ( ) ) ;
} catch ( ex ) {
log . error ( ex ) ;
res . status ( 500 ) . end ( ) ;
}
} ) ;
2020-08-11 12:24:59 -04:00
/ * *
* @ param { string [ ] } channels
2023-04-29 20:29:54 -04:00
* @ returns { function ( ) : void }
2020-08-11 12:24:59 -04:00
* /
2020-06-02 13:24:53 -04:00
const subscriptionHeartbeat = channels => {
const interval = 6 * 60 ;
2017-06-03 14:50:53 -04:00
const tellSubscribed = ( ) => {
2020-06-02 13:24:53 -04:00
channels . forEach ( channel => redisClient . set ( ` ${ redisPrefix } subscribed: ${ channel } ` , '1' , 'EX' , interval * 3 ) ) ;
2017-06-03 14:50:53 -04:00
} ;
2020-06-02 13:24:53 -04:00
2017-06-03 14:50:53 -04:00
tellSubscribed ( ) ;
2020-06-02 13:24:53 -04:00
const heartbeat = setInterval ( tellSubscribed , interval * 1000 ) ;
2017-06-03 14:50:53 -04:00
return ( ) => {
clearInterval ( heartbeat ) ;
} ;
} ;
2017-02-07 08:37:12 -05:00
2022-03-21 14:08:29 -04:00
/ * *
* @ param { string } channel
2023-09-01 11:44:28 -04:00
* @ param { string } message
2022-03-21 14:08:29 -04:00
* /
2023-09-01 11:44:28 -04:00
const onRedisMessage = ( channel , message ) => {
2022-03-21 14:08:29 -04:00
const callbacks = subs [ channel ] ;
2023-09-01 11:44:28 -04:00
log . silly ( ` New message on channel ${ redisPrefix } ${ channel } ` ) ;
2022-03-21 14:08:29 -04:00
if ( ! callbacks ) {
return ;
}
2023-06-09 13:29:16 -04:00
const json = parseJSON ( message , null ) ;
if ( ! json ) return ;
callbacks . forEach ( callback => callback ( json ) ) ;
2022-03-21 14:08:29 -04:00
} ;
2023-09-01 11:44:28 -04:00
redisSubscribeClient . on ( "message" , onRedisMessage ) ;
2022-03-21 14:08:29 -04:00
2023-07-28 06:06:29 -04:00
/ * *
* @ callback SubscriptionListener
* @ param { ReturnType < parseJSON > } json of the message
* @ returns void
* /
2020-08-11 12:24:59 -04:00
/ * *
* @ param { string } channel
2023-07-28 06:06:29 -04:00
* @ param { SubscriptionListener } callback
2020-08-11 12:24:59 -04:00
* /
2017-04-16 22:32:30 -04:00
const subscribe = ( channel , callback ) => {
2017-05-20 11:31:47 -04:00
log . silly ( ` Adding listener for ${ channel } ` ) ;
2020-08-11 12:24:59 -04:00
2022-03-21 14:08:29 -04:00
subs [ channel ] = subs [ channel ] || [ ] ;
if ( subs [ channel ] . length === 0 ) {
log . verbose ( ` Subscribe ${ channel } ` ) ;
2023-09-01 11:44:28 -04:00
redisSubscribeClient . subscribe ( channel , ( err , count ) => {
if ( err ) {
log . error ( ` Error subscribing to ${ channel } ` ) ;
}
else {
redisSubscriptions . set ( count ) ;
}
} ) ;
2022-03-21 14:08:29 -04:00
}
subs [ channel ] . push ( callback ) ;
2017-05-20 11:31:47 -04:00
} ;
2017-02-03 12:27:42 -05:00
2020-08-11 12:24:59 -04:00
/ * *
* @ param { string } channel
2023-07-28 06:06:29 -04:00
* @ param { SubscriptionListener } callback
2020-08-11 12:24:59 -04:00
* /
2022-01-07 13:50:12 -05:00
const unsubscribe = ( channel , callback ) => {
log . silly ( ` Removing listener for ${ channel } ` ) ;
2020-08-11 12:24:59 -04:00
2022-03-21 14:08:29 -04:00
if ( ! subs [ channel ] ) {
return ;
}
subs [ channel ] = subs [ channel ] . filter ( item => item !== callback ) ;
if ( subs [ channel ] . length === 0 ) {
log . verbose ( ` Unsubscribe ${ channel } ` ) ;
2023-09-01 11:44:28 -04:00
redisSubscribeClient . unsubscribe ( channel , ( err , count ) => {
if ( err ) {
log . error ( ` Error unsubscribing to ${ channel } ` ) ;
}
else {
redisSubscriptions . set ( count ) ;
}
} ) ;
2022-03-21 14:08:29 -04:00
delete subs [ channel ] ;
}
2017-05-20 11:31:47 -04:00
} ;
2017-02-03 12:27:42 -05:00
2020-08-11 12:24:59 -04:00
const FALSE _VALUES = [
false ,
0 ,
2020-11-23 11:35:14 -05:00
'0' ,
'f' ,
'F' ,
'false' ,
'FALSE' ,
'off' ,
'OFF' ,
2020-08-11 12:24:59 -04:00
] ;
/ * *
* @ param { any } value
2023-04-29 20:29:54 -04:00
* @ returns { boolean }
2020-08-11 12:24:59 -04:00
* /
const isTruthy = value =>
value && ! FALSE _VALUES . includes ( value ) ;
/ * *
* @ param { any } req
* @ param { any } res
2023-04-29 20:29:54 -04:00
* @ param { function ( Error = ) : void } next
2020-08-11 12:24:59 -04:00
* /
2017-04-16 22:32:30 -04:00
const allowCrossDomain = ( req , res , next ) => {
2017-05-20 11:31:47 -04:00
res . header ( 'Access-Control-Allow-Origin' , '*' ) ;
res . header ( 'Access-Control-Allow-Headers' , 'Authorization, Accept, Cache-Control' ) ;
res . header ( 'Access-Control-Allow-Methods' , 'GET, OPTIONS' ) ;
2017-02-05 17:37:25 -05:00
2017-05-20 11:31:47 -04:00
next ( ) ;
} ;
2017-02-05 17:37:25 -05:00
2020-08-11 12:24:59 -04:00
/ * *
* @ param { any } req
* @ param { any } res
2023-04-29 20:29:54 -04:00
* @ param { function ( Error = ) : void } next
2020-08-11 12:24:59 -04:00
* /
2017-04-16 22:32:30 -04:00
const setRequestId = ( req , res , next ) => {
2017-05-20 11:31:47 -04:00
req . requestId = uuid . v4 ( ) ;
res . header ( 'X-Request-Id' , req . requestId ) ;
2017-02-01 19:31:09 -05:00
2017-05-20 11:31:47 -04:00
next ( ) ;
} ;
2017-02-01 19:31:09 -05:00
2020-08-11 12:24:59 -04:00
/ * *
* @ param { any } req
* @ param { any } res
2023-04-29 20:29:54 -04:00
* @ param { function ( Error = ) : void } next
2020-08-11 12:24:59 -04:00
* /
2017-12-12 09:13:24 -05:00
const setRemoteAddress = ( req , res , next ) => {
req . remoteAddress = req . connection . remoteAddress ;
next ( ) ;
} ;
2021-09-26 07:23:28 -04:00
/ * *
* @ param { any } req
* @ param { string [ ] } necessaryScopes
2023-04-29 20:29:54 -04:00
* @ returns { boolean }
2021-09-26 07:23:28 -04:00
* /
const isInScope = ( req , necessaryScopes ) =>
req . scopes . some ( scope => necessaryScopes . includes ( scope ) ) ;
2020-08-11 12:24:59 -04:00
/ * *
* @ param { string } token
* @ param { any } req
2023-04-29 20:29:54 -04:00
* @ returns { Promise . < void > }
2020-08-11 12:24:59 -04:00
* /
const accountFromToken = ( token , req ) => new Promise ( ( resolve , reject ) => {
2017-04-16 22:32:30 -04:00
pgPool . connect ( ( err , client , done ) => {
2017-02-01 19:31:09 -05:00
if ( err ) {
2020-08-11 12:24:59 -04:00
reject ( err ) ;
2017-05-20 11:31:47 -04:00
return ;
2017-02-01 19:31:09 -05:00
}
2020-11-12 17:05:24 -05:00
client . query ( 'SELECT oauth_access_tokens.id, oauth_access_tokens.resource_owner_id, users.account_id, users.chosen_languages, oauth_access_tokens.scopes, devices.device_id FROM oauth_access_tokens INNER JOIN users ON oauth_access_tokens.resource_owner_id = users.id LEFT OUTER JOIN devices ON oauth_access_tokens.id = devices.access_token_id WHERE oauth_access_tokens.token = $1 AND oauth_access_tokens.revoked_at IS NULL LIMIT 1' , [ token ] , ( err , result ) => {
2017-05-20 11:31:47 -04:00
done ( ) ;
2017-02-01 19:31:09 -05:00
2017-04-16 22:32:30 -04:00
if ( err ) {
2020-08-11 12:24:59 -04:00
reject ( err ) ;
2017-05-20 11:31:47 -04:00
return ;
2017-04-16 22:32:30 -04:00
}
2017-02-01 19:31:09 -05:00
2017-04-16 22:32:30 -04:00
if ( result . rows . length === 0 ) {
2017-05-20 11:31:47 -04:00
err = new Error ( 'Invalid access token' ) ;
2020-08-11 12:24:59 -04:00
err . status = 401 ;
2019-05-24 09:21:42 -04:00
2020-08-11 12:24:59 -04:00
reject ( err ) ;
2019-05-24 09:21:42 -04:00
return ;
}
2020-11-12 17:05:24 -05:00
req . accessTokenId = result . rows [ 0 ] . id ;
2020-08-11 12:24:59 -04:00
req . scopes = result . rows [ 0 ] . scopes . split ( ' ' ) ;
2017-05-20 11:31:47 -04:00
req . accountId = result . rows [ 0 ] . account _id ;
2018-07-13 21:59:31 -04:00
req . chosenLanguages = result . rows [ 0 ] . chosen _languages ;
2020-06-02 13:24:53 -04:00
req . deviceId = result . rows [ 0 ] . device _id ;
2017-02-03 18:34:31 -05:00
2020-08-11 12:24:59 -04:00
resolve ( ) ;
2017-05-20 11:31:47 -04:00
} ) ;
} ) ;
2020-08-11 12:24:59 -04:00
} ) ;
2017-02-03 18:34:31 -05:00
2020-08-11 12:24:59 -04:00
/ * *
* @ param { any } req
2023-04-29 20:29:54 -04:00
* @ returns { Promise . < void > }
2020-08-11 12:24:59 -04:00
* /
2023-03-06 15:00:10 -05:00
const accountFromRequest = ( req ) => new Promise ( ( resolve , reject ) => {
2017-05-29 12:20:53 -04:00
const authorization = req . headers . authorization ;
2020-08-11 12:24:59 -04:00
const location = url . parse ( req . url , true ) ;
const accessToken = location . query . access _token || req . headers [ 'sec-websocket-protocol' ] ;
2017-02-03 18:34:31 -05:00
2017-05-21 15:13:11 -04:00
if ( ! authorization && ! accessToken ) {
2023-03-06 15:00:10 -05:00
const err = new Error ( 'Missing access token' ) ;
err . status = 401 ;
2017-02-01 19:31:09 -05:00
2023-03-06 15:00:10 -05:00
reject ( err ) ;
return ;
2017-04-16 22:32:30 -04:00
}
2017-02-02 11:10:59 -05:00
2017-05-21 15:13:11 -04:00
const token = authorization ? authorization . replace ( /^Bearer / , '' ) : accessToken ;
2017-02-02 07:56:14 -05:00
2020-08-11 12:24:59 -04:00
resolve ( accountFromToken ( token , req ) ) ;
} ) ;
/ * *
* @ param { any } req
2023-06-09 13:29:16 -04:00
* @ returns { string | undefined }
2020-08-11 12:24:59 -04:00
* /
const channelNameFromPath = req => {
const { path , query } = req ;
const onlyMedia = isTruthy ( query . only _media ) ;
2021-12-25 16:55:06 -05:00
switch ( path ) {
2020-08-11 12:24:59 -04:00
case '/api/v1/streaming/user' :
return 'user' ;
case '/api/v1/streaming/user/notification' :
return 'user:notification' ;
case '/api/v1/streaming/public' :
return onlyMedia ? 'public:media' : 'public' ;
case '/api/v1/streaming/public/local' :
return onlyMedia ? 'public:local:media' : 'public:local' ;
case '/api/v1/streaming/public/remote' :
return onlyMedia ? 'public:remote:media' : 'public:remote' ;
case '/api/v1/streaming/hashtag' :
return 'hashtag' ;
case '/api/v1/streaming/hashtag/local' :
return 'hashtag:local' ;
case '/api/v1/streaming/direct' :
return 'direct' ;
case '/api/v1/streaming/list' :
return 'list' ;
2020-11-23 11:35:14 -05:00
default :
return undefined ;
2020-08-11 12:24:59 -04:00
}
2017-05-20 11:31:47 -04:00
} ;
2017-02-04 21:19:04 -05:00
2020-08-11 12:24:59 -04:00
const PUBLIC _CHANNELS = [
2017-12-12 09:13:24 -05:00
'public' ,
2018-05-21 06:43:38 -04:00
'public:media' ,
2017-12-12 09:13:24 -05:00
'public:local' ,
2018-05-21 06:43:38 -04:00
'public:local:media' ,
2020-05-10 04:36:18 -04:00
'public:remote' ,
'public:remote:media' ,
2017-12-12 09:13:24 -05:00
'hashtag' ,
'hashtag:local' ,
] ;
2020-08-11 12:24:59 -04:00
/ * *
* @ param { any } req
2023-08-04 10:11:30 -04:00
* @ param { string | undefined } channelName
2023-04-29 20:29:54 -04:00
* @ returns { Promise . < void > }
2020-08-11 12:24:59 -04:00
* /
const checkScopes = ( req , channelName ) => new Promise ( ( resolve , reject ) => {
log . silly ( req . requestId , ` Checking OAuth scopes for ${ channelName } ` ) ;
// When accessing public channels, no scopes are needed
if ( PUBLIC _CHANNELS . includes ( channelName ) ) {
resolve ( ) ;
return ;
}
2019-05-24 09:21:42 -04:00
2020-08-11 12:24:59 -04:00
// The `read` scope has the highest priority, if the token has it
// then it can access all streams
const requiredScopes = [ 'read' ] ;
// When accessing specifically the notifications stream,
// we need a read:notifications, while in all other cases,
// we can allow access with read:statuses. Mind that the
// user stream will not contain notifications unless
// the token has either read or read:notifications scope
// as well, this is handled separately.
if ( channelName === 'user:notification' ) {
requiredScopes . push ( 'read:notifications' ) ;
} else {
requiredScopes . push ( 'read:statuses' ) ;
2019-05-24 09:21:42 -04:00
}
2017-12-12 09:13:24 -05:00
2021-10-12 23:02:55 -04:00
if ( req . scopes && requiredScopes . some ( requiredScope => req . scopes . includes ( requiredScope ) ) ) {
2020-08-11 12:24:59 -04:00
resolve ( ) ;
return ;
}
2017-05-29 12:20:53 -04:00
2020-08-11 12:24:59 -04:00
const err = new Error ( 'Access token does not cover required scopes' ) ;
err . status = 401 ;
reject ( err ) ;
} ) ;
2017-12-12 09:13:24 -05:00
2020-08-11 12:24:59 -04:00
/ * *
* @ param { any } info
* @ param { function ( boolean , number , string ) : void } callback
* /
const wsVerifyClient = ( info , callback ) => {
// When verifying the websockets connection, we no longer pre-emptively
// check OAuth scopes and drop the connection if they're missing. We only
// drop the connection if access without token is not allowed by environment
// variables. OAuth scope checks are moved to the point of subscription
// to a specific stream.
2023-03-06 15:00:10 -05:00
accountFromRequest ( info . req ) . then ( ( ) => {
2020-08-11 12:24:59 -04:00
callback ( true , undefined , undefined ) ;
} ) . catch ( err => {
log . error ( info . req . requestId , err . toString ( ) ) ;
callback ( false , 401 , 'Unauthorized' ) ;
} ) ;
} ;
2020-11-12 17:05:24 -05:00
/ * *
* @ typedef SystemMessageHandlers
* @ property { function ( ) : void } onKill
* /
/ * *
* @ param { any } req
* @ param { SystemMessageHandlers } eventHandlers
2023-06-09 13:29:16 -04:00
* @ returns { function ( object ) : void }
2020-11-12 17:05:24 -05:00
* /
const createSystemMessageListener = ( req , eventHandlers ) => {
return message => {
2023-06-09 13:29:16 -04:00
const { event } = message ;
2020-11-12 17:05:24 -05:00
log . silly ( req . requestId , ` System message for ${ req . accountId } : ${ event } ` ) ;
if ( event === 'kill' ) {
log . verbose ( req . requestId , ` Closing connection for ${ req . accountId } due to expired access token ` ) ;
eventHandlers . onKill ( ) ;
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
} else if ( event === 'filters_changed' ) {
log . verbose ( req . requestId , ` Invalidating filters cache for ${ req . accountId } ` ) ;
req . cachedFilters = null ;
2020-11-12 17:05:24 -05:00
}
2020-11-23 11:35:14 -05:00
} ;
2020-11-12 17:05:24 -05:00
} ;
/ * *
* @ param { any } req
* @ param { any } res
* /
const subscribeHttpToSystemChannel = ( req , res ) => {
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
const accessTokenChannelId = ` timeline:access_token: ${ req . accessTokenId } ` ;
const systemChannelId = ` timeline:system: ${ req . accountId } ` ;
2020-11-12 17:05:24 -05:00
const listener = createSystemMessageListener ( req , {
2021-12-25 16:55:06 -05:00
onKill ( ) {
2020-11-12 17:05:24 -05:00
res . end ( ) ;
} ,
} ) ;
res . on ( 'close' , ( ) => {
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
unsubscribe ( ` ${ redisPrefix } ${ accessTokenChannelId } ` , listener ) ;
2020-11-12 17:05:24 -05:00
unsubscribe ( ` ${ redisPrefix } ${ systemChannelId } ` , listener ) ;
2023-08-04 10:11:30 -04:00
connectedChannels . labels ( { type : 'eventsource' , channel : 'system' } ) . dec ( 2 ) ;
2020-11-12 17:05:24 -05:00
} ) ;
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
subscribe ( ` ${ redisPrefix } ${ accessTokenChannelId } ` , listener ) ;
2020-11-12 17:05:24 -05:00
subscribe ( ` ${ redisPrefix } ${ systemChannelId } ` , listener ) ;
2023-08-04 10:11:30 -04:00
connectedChannels . labels ( { type : 'eventsource' , channel : 'system' } ) . inc ( 2 ) ;
2020-11-12 17:05:24 -05:00
} ;
2020-08-11 12:24:59 -04:00
/ * *
* @ param { any } req
* @ param { any } res
* @ param { function ( Error = ) : void } next
* /
2017-05-29 12:20:53 -04:00
const authenticationMiddleware = ( req , res , next ) => {
if ( req . method === 'OPTIONS' ) {
next ( ) ;
return ;
}
2023-08-04 10:11:30 -04:00
const channelName = channelNameFromPath ( req ) ;
// If no channelName can be found for the request, then we should terminate
// the connection, as there's nothing to stream back
if ( ! channelName ) {
const err = new Error ( 'Unknown channel requested' ) ;
err . status = 400 ;
next ( err ) ;
return ;
}
accountFromRequest ( req ) . then ( ( ) => checkScopes ( req , channelName ) ) . then ( ( ) => {
2020-11-12 17:05:24 -05:00
subscribeHttpToSystemChannel ( req , res ) ;
} ) . then ( ( ) => {
2020-08-11 12:24:59 -04:00
next ( ) ;
} ) . catch ( err => {
next ( err ) ;
} ) ;
2017-05-29 12:20:53 -04:00
} ;
2020-08-11 12:24:59 -04:00
/ * *
* @ param { Error } err
* @ param { any } req
* @ param { any } res
* @ param { function ( Error = ) : void } next
* /
const errorMiddleware = ( err , req , res , next ) => {
2017-05-28 10:25:26 -04:00
log . error ( req . requestId , err . toString ( ) ) ;
2020-08-11 12:24:59 -04:00
if ( res . headersSent ) {
2020-11-23 11:35:14 -05:00
next ( err ) ;
return ;
2020-08-11 12:24:59 -04:00
}
res . writeHead ( err . status || 500 , { 'Content-Type' : 'application/json' } ) ;
res . end ( JSON . stringify ( { error : err . status ? err . toString ( ) : 'An unexpected error occurred' } ) ) ;
2017-05-20 11:31:47 -04:00
} ;
2017-02-04 21:19:04 -05:00
2020-08-11 12:24:59 -04:00
/ * *
2021-12-25 16:55:06 -05:00
* @ param { array } arr
2020-08-11 12:24:59 -04:00
* @ param { number = } shift
2023-04-29 20:29:54 -04:00
* @ returns { string }
2020-08-11 12:24:59 -04:00
* /
2017-04-16 22:32:30 -04:00
const placeholders = ( arr , shift = 0 ) => arr . map ( ( _ , i ) => ` $ ${ i + 1 + shift } ` ) . join ( ', ' ) ;
2017-02-01 19:31:09 -05:00
2020-08-11 12:24:59 -04:00
/ * *
* @ param { string } listId
* @ param { any } req
2023-04-29 20:29:54 -04:00
* @ returns { Promise . < void > }
2020-08-11 12:24:59 -04:00
* /
const authorizeListAccess = ( listId , req ) => new Promise ( ( resolve , reject ) => {
const { accountId } = req ;
2017-11-17 18:16:48 -05:00
pgPool . connect ( ( err , client , done ) => {
if ( err ) {
2020-08-11 12:24:59 -04:00
reject ( ) ;
2017-11-17 18:16:48 -05:00
return ;
}
2020-08-11 12:24:59 -04:00
client . query ( 'SELECT id, account_id FROM lists WHERE id = $1 LIMIT 1' , [ listId ] , ( err , result ) => {
2017-11-17 18:16:48 -05:00
done ( ) ;
2020-08-11 12:24:59 -04:00
if ( err || result . rows . length === 0 || result . rows [ 0 ] . account _id !== accountId ) {
reject ( ) ;
2017-11-17 18:16:48 -05:00
return ;
}
2020-08-11 12:24:59 -04:00
resolve ( ) ;
2017-11-17 18:16:48 -05:00
} ) ;
} ) ;
2020-08-11 12:24:59 -04:00
} ) ;
2017-11-17 18:16:48 -05:00
2020-08-11 12:24:59 -04:00
/ * *
* @ param { string [ ] } ids
* @ param { any } req
* @ param { function ( string , string ) : void } output
2023-07-28 06:06:29 -04:00
* @ param { undefined | function ( string [ ] , SubscriptionListener ) : void } attachCloseHandler
2020-08-11 12:24:59 -04:00
* @ param { boolean = } needsFiltering
2023-07-28 06:06:29 -04:00
* @ returns { SubscriptionListener }
2020-08-11 12:24:59 -04:00
* /
2021-09-26 07:23:28 -04:00
const streamFrom = ( ids , req , output , attachCloseHandler , needsFiltering = false ) => {
2021-12-25 16:55:06 -05:00
const accountId = req . accountId || req . remoteAddress ;
2020-06-02 13:24:53 -04:00
2021-09-26 07:23:28 -04:00
log . verbose ( req . requestId , ` Starting stream from ${ ids . join ( ', ' ) } for ${ accountId } ` ) ;
2017-04-16 22:32:30 -04:00
2023-07-27 09:38:18 -04:00
const transmit = ( event , payload ) => {
// TODO: Replace "string"-based delete payloads with object payloads:
const encodedPayload = typeof payload === 'object' ? JSON . stringify ( payload ) : payload ;
2017-02-02 07:56:14 -05:00
2023-07-27 09:38:18 -04:00
log . silly ( req . requestId , ` Transmitting for ${ accountId } : ${ event } ${ encodedPayload } ` ) ;
output ( event , encodedPayload ) ;
} ;
2017-02-02 07:56:14 -05:00
2023-07-27 09:38:18 -04:00
// The listener used to process each message off the redis subscription,
// message here is an object with an `event` and `payload` property. Some
// events also include a queued_at value, but this is being removed shortly.
2023-07-28 06:06:29 -04:00
/** @type {SubscriptionListener} */
2023-07-27 09:38:18 -04:00
const listener = message => {
const { event , payload } = message ;
// Streaming only needs to apply filtering to some channels and only to
// some events. This is because majority of the filtering happens on the
// Ruby on Rails side when producing the event for streaming.
//
// The only events that require filtering from the streaming server are
// `update` and `status.update`, all other events are transmitted to the
// client as soon as they're received (pass-through).
//
// The channels that need filtering are determined in the function
// `channelNameToIds` defined below:
if ( ! needsFiltering || ( event !== 'update' && event !== 'status.update' ) ) {
transmit ( event , payload ) ;
2018-04-17 07:49:09 -04:00
return ;
}
2017-02-02 07:56:14 -05:00
2023-07-27 09:38:18 -04:00
// The rest of the logic from here on in this function is to handle
// filtering of statuses:
2017-04-16 22:32:30 -04:00
2023-07-27 09:38:18 -04:00
// Filter based on language:
2023-07-27 09:12:10 -04:00
if ( Array . isArray ( req . chosenLanguages ) && payload . language !== null && req . chosenLanguages . indexOf ( payload . language ) === - 1 ) {
log . silly ( req . requestId , ` Message ${ payload . id } filtered by language ( ${ payload . language } ) ` ) ;
2018-04-17 07:49:09 -04:00
return ;
}
// When the account is not logged in, it is not necessary to confirm the block or mute
if ( ! req . accountId ) {
2023-07-27 09:38:18 -04:00
transmit ( event , payload ) ;
2018-04-17 07:49:09 -04:00
return ;
}
2023-07-27 09:38:18 -04:00
// Filter based on domain blocks, blocks, mutes, or custom filters:
const targetAccountIds = [ payload . account . id ] . concat ( payload . mentions . map ( item => item . id ) ) ;
const accountDomain = payload . account . acct . split ( '@' ) [ 1 ] ;
// TODO: Move this logic out of the message handling loop
pgPool . connect ( ( err , client , releasePgConnection ) => {
2018-04-17 07:49:09 -04:00
if ( err ) {
log . error ( err ) ;
return ;
}
const queries = [
2021-12-25 16:55:06 -05:00
client . query ( ` SELECT 1
FROM blocks
WHERE ( account _id = $1 AND target _account _id IN ( $ { placeholders ( targetAccountIds , 2 ) } ) )
OR ( account _id = $2 AND target _account _id = $1 )
UNION
SELECT 1
FROM mutes
WHERE account _id = $1
2023-07-27 09:12:10 -04:00
AND target _account _id IN ( $ { placeholders ( targetAccountIds , 2 ) } ) ` , [req.accountId, payload.account.id].concat(targetAccountIds)),
2018-04-17 07:49:09 -04:00
] ;
if ( accountDomain ) {
queries . push ( client . query ( 'SELECT 1 FROM account_domain_blocks WHERE account_id = $1 AND domain = $2' , [ req . accountId , accountDomain ] ) ) ;
}
2023-07-27 09:12:10 -04:00
if ( ! payload . filtered && ! req . cachedFilters ) {
2022-11-14 20:09:58 -05:00
queries . push ( client . query ( 'SELECT filter.id AS id, filter.phrase AS title, filter.context AS context, filter.expires_at AS expires_at, filter.action AS filter_action, keyword.keyword AS keyword, keyword.whole_word AS whole_word FROM custom_filter_keywords keyword JOIN custom_filters filter ON keyword.custom_filter_id = filter.id WHERE filter.account_id = $1 AND (filter.expires_at IS NULL OR filter.expires_at > NOW())' , [ req . accountId ] ) ) ;
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
}
2018-04-17 07:49:09 -04:00
Promise . all ( queries ) . then ( values => {
2023-07-27 09:38:18 -04:00
releasePgConnection ( ) ;
2018-04-17 07:49:09 -04:00
2023-07-27 09:38:18 -04:00
// Handling blocks & mutes and domain blocks: If one of those applies,
// then we don't transmit the payload of the event to the client
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
if ( values [ 0 ] . rows . length > 0 || ( accountDomain && values [ 1 ] . rows . length > 0 ) ) {
2017-05-26 18:53:48 -04:00
return ;
}
2023-07-27 09:38:18 -04:00
// If the payload already contains the `filtered` property, it means
2023-07-28 13:11:58 -04:00
// that filtering has been applied on the ruby on rails side, as
2023-07-27 09:38:18 -04:00
// such, we don't need to construct or apply the filters in streaming:
if ( Object . prototype . hasOwnProperty . call ( payload , "filtered" ) ) {
transmit ( event , payload ) ;
return ;
}
// Handling for constructing the custom filters and caching them on the request
// TODO: Move this logic out of the message handling lifecycle
if ( ! req . cachedFilters ) {
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
const filterRows = values [ accountDomain ? 2 : 1 ] . rows ;
2023-07-27 09:38:18 -04:00
req . cachedFilters = filterRows . reduce ( ( cache , filter ) => {
if ( cache [ filter . id ] ) {
cache [ filter . id ] . keywords . push ( [ filter . keyword , filter . whole _word ] ) ;
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
} else {
2023-07-27 09:38:18 -04:00
cache [ filter . id ] = {
keywords : [ [ filter . keyword , filter . whole _word ] ] ,
expires _at : filter . expires _at ,
filter : {
id : filter . id ,
title : filter . title ,
context : filter . context ,
expires _at : filter . expires _at ,
// filter.filter_action is the value from the
// custom_filters.action database column, it is an integer
// representing a value in an enum defined by Ruby on Rails:
//
// enum { warn: 0, hide: 1 }
filter _action : [ 'warn' , 'hide' ] [ filter . filter _action ] ,
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
} ,
} ;
}
return cache ;
} , { } ) ;
2023-07-27 09:38:18 -04:00
// Construct the regular expressions for the custom filters: This
// needs to be done in a separate loop as the database returns one
// filterRow per keyword, so we need all the keywords before
// constructing the regular expression
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
Object . keys ( req . cachedFilters ) . forEach ( ( key ) => {
req . cachedFilters [ key ] . regexp = new RegExp ( req . cachedFilters [ key ] . keywords . map ( ( [ keyword , whole _word ] ) => {
2022-12-18 10:51:37 -05:00
let expr = keyword . replace ( /[.*+?^${}()|[\]\\]/g , '\\$&' ) ;
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
if ( whole _word ) {
if ( /^[\w]/ . test ( expr ) ) {
expr = ` \\ b ${ expr } ` ;
}
if ( /[\w]$/ . test ( expr ) ) {
expr = ` ${ expr } \\ b ` ;
}
}
return expr ;
} ) . join ( '|' ) , 'i' ) ;
} ) ;
}
2023-07-27 09:38:18 -04:00
// Apply cachedFilters against the payload, constructing a
// `filter_results` array of FilterResult entities
if ( req . cachedFilters ) {
2023-07-27 09:12:10 -04:00
const status = payload ;
2023-07-27 09:38:18 -04:00
// TODO: Calculate searchableContent in Ruby on Rails:
const searchableContent = ( [ status . spoiler _text || '' , status . content ] . concat ( ( status . poll && status . poll . options ) ? status . poll . options . map ( option => option . title ) : [ ] ) ) . concat ( status . media _attachments . map ( att => att . description ) ) . join ( '\n\n' ) . replace ( /<br\s*\/?>/g , '\n' ) . replace ( /<\/p><p>/g , '\n\n' ) ;
const searchableTextContent = JSDOM . fragment ( searchableContent ) . textContent ;
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
const now = new Date ( ) ;
2023-07-27 09:38:18 -04:00
const filter _results = Object . values ( req . cachedFilters ) . reduce ( ( results , cachedFilter ) => {
// Check the filter hasn't expired before applying:
if ( cachedFilter . expires _at !== null && cachedFilter . expires _at < now ) {
2023-07-28 13:11:58 -04:00
return results ;
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
}
2023-07-27 09:38:18 -04:00
// Just in-case JSDOM fails to find textContent in searchableContent
if ( ! searchableTextContent ) {
2023-07-28 13:11:58 -04:00
return results ;
2023-07-27 09:38:18 -04:00
}
const keyword _matches = searchableTextContent . match ( cachedFilter . regexp ) ;
if ( keyword _matches ) {
// results is an Array of FilterResult; status_matches is always
// null as we only are only applying the keyword-based custom
// filters, not the status-based custom filters.
// https://docs.joinmastodon.org/entities/FilterResult/
results . push ( {
filter : cachedFilter . filter ,
keyword _matches ,
status _matches : null
} ) ;
}
2023-07-28 13:11:58 -04:00
return results ;
2023-07-27 09:38:18 -04:00
} , [ ] ) ;
// Send the payload + the FilterResults as the `filtered` property
// to the streaming connection. To reach this code, the `event` must
// have been either `update` or `status.update`, meaning the
// `payload` is a Status entity, which has a `filtered` property:
//
// filtered: https://docs.joinmastodon.org/entities/Status/#filtered
transmit ( event , {
... payload ,
filtered : filter _results
} ) ;
2023-07-27 09:12:10 -04:00
} else {
2023-07-27 09:38:18 -04:00
transmit ( event , payload ) ;
2023-07-27 09:12:10 -04:00
}
2018-04-17 07:49:09 -04:00
} ) . catch ( err => {
log . error ( err ) ;
2023-07-28 11:59:31 -04:00
releasePgConnection ( ) ;
2017-05-20 11:31:47 -04:00
} ) ;
2018-04-17 07:49:09 -04:00
} ) ;
2017-05-20 11:31:47 -04:00
} ;
2017-04-16 22:32:30 -04:00
2020-06-02 13:24:53 -04:00
ids . forEach ( id => {
subscribe ( ` ${ redisPrefix } ${ id } ` , listener ) ;
} ) ;
2023-07-28 06:06:29 -04:00
if ( typeof attachCloseHandler === 'function' ) {
2020-08-11 12:24:59 -04:00
attachCloseHandler ( ids . map ( id => ` ${ redisPrefix } ${ id } ` ) , listener ) ;
}
return listener ;
2017-05-20 11:31:47 -04:00
} ;
2017-02-01 19:31:09 -05:00
2020-08-11 12:24:59 -04:00
/ * *
* @ param { any } req
* @ param { any } res
2023-04-29 20:29:54 -04:00
* @ returns { function ( string , string ) : void }
2020-08-11 12:24:59 -04:00
* /
2017-04-16 22:32:30 -04:00
const streamToHttp = ( req , res ) => {
2017-12-12 09:13:24 -05:00
const accountId = req . accountId || req . remoteAddress ;
2023-08-04 10:11:30 -04:00
const channelName = channelNameFromPath ( req ) ;
connectedClients . labels ( { type : 'eventsource' } ) . inc ( ) ;
// In theory we'll always have a channel name, but channelNameFromPath can return undefined:
if ( typeof channelName === 'string' ) {
connectedChannels . labels ( { type : 'eventsource' , channel : channelName } ) . inc ( ) ;
}
2017-05-20 11:31:47 -04:00
res . setHeader ( 'Content-Type' , 'text/event-stream' ) ;
2020-01-24 14:51:33 -05:00
res . setHeader ( 'Cache-Control' , 'no-store' ) ;
2017-05-20 11:31:47 -04:00
res . setHeader ( 'Transfer-Encoding' , 'chunked' ) ;
2017-02-03 18:34:31 -05:00
2020-01-24 14:51:33 -05:00
res . write ( ':)\n' ) ;
2017-05-20 11:31:47 -04:00
const heartbeat = setInterval ( ( ) => res . write ( ':thump\n' ) , 15000 ) ;
2017-02-03 18:34:31 -05:00
2017-04-16 22:32:30 -04:00
req . on ( 'close' , ( ) => {
2017-12-12 09:13:24 -05:00
log . verbose ( req . requestId , ` Ending stream for ${ accountId } ` ) ;
2023-08-04 10:11:30 -04:00
// We decrement these counters here instead of in streamHttpEnd as in that
// method we don't have knowledge of the channel names
connectedClients . labels ( { type : 'eventsource' } ) . dec ( ) ;
// In theory we'll always have a channel name, but channelNameFromPath can return undefined:
if ( typeof channelName === 'string' ) {
connectedChannels . labels ( { type : 'eventsource' , channel : channelName } ) . dec ( ) ;
}
2017-05-20 11:31:47 -04:00
clearInterval ( heartbeat ) ;
} ) ;
2017-02-02 09:20:31 -05:00
2017-04-16 22:32:30 -04:00
return ( event , payload ) => {
2017-05-20 11:31:47 -04:00
res . write ( ` event: ${ event } \n ` ) ;
res . write ( ` data: ${ payload } \n \n ` ) ;
} ;
} ;
2017-02-01 19:31:09 -05:00
2020-08-11 12:24:59 -04:00
/ * *
* @ param { any } req
* @ param { function ( ) : void } [ closeHandler ]
2023-07-28 06:06:29 -04:00
* @ returns { function ( string [ ] , SubscriptionListener ) : void }
2020-08-11 12:24:59 -04:00
* /
2023-07-28 06:06:29 -04:00
const streamHttpEnd = ( req , closeHandler = undefined ) => ( ids , listener ) => {
2017-04-16 22:32:30 -04:00
req . on ( 'close' , ( ) => {
2020-06-02 13:24:53 -04:00
ids . forEach ( id => {
2023-07-28 06:06:29 -04:00
unsubscribe ( id , listener ) ;
2020-06-02 13:24:53 -04:00
} ) ;
2017-06-03 14:50:53 -04:00
if ( closeHandler ) {
closeHandler ( ) ;
}
2017-05-20 11:31:47 -04:00
} ) ;
} ;
2017-02-03 18:34:31 -05:00
2020-08-11 12:24:59 -04:00
/ * *
* @ param { any } req
* @ param { any } ws
* @ param { string [ ] } streamName
2023-04-29 20:29:54 -04:00
* @ returns { function ( string , string ) : void }
2020-08-11 12:24:59 -04:00
* /
const streamToWs = ( req , ws , streamName ) => ( event , payload ) => {
2017-05-28 10:25:26 -04:00
if ( ws . readyState !== ws . OPEN ) {
log . error ( req . requestId , 'Tried writing to closed socket' ) ;
return ;
}
2017-02-03 18:34:31 -05:00
2023-06-10 12:35:57 -04:00
ws . send ( JSON . stringify ( { stream : streamName , event , payload } ) , ( err ) => {
if ( err ) {
log . error ( req . requestId , ` Failed to send to websocket: ${ err } ` ) ;
}
} ) ;
2017-05-20 11:31:47 -04:00
} ;
2017-02-03 18:34:31 -05:00
2020-08-11 12:24:59 -04:00
/ * *
* @ param { any } res
* /
2018-10-11 13:24:43 -04:00
const httpNotFound = res => {
res . writeHead ( 404 , { 'Content-Type' : 'application/json' } ) ;
res . end ( JSON . stringify ( { error : 'Not found' } ) ) ;
} ;
2023-08-04 10:11:30 -04:00
const api = express . Router ( ) ;
2018-08-26 05:54:25 -04:00
2023-08-04 10:11:30 -04:00
app . use ( api ) ;
api . use ( setRequestId ) ;
api . use ( setRemoteAddress ) ;
api . use ( allowCrossDomain ) ;
2018-08-26 05:54:25 -04:00
2023-08-04 10:11:30 -04:00
api . use ( authenticationMiddleware ) ;
api . use ( errorMiddleware ) ;
api . get ( '/api/v1/streaming/*' , ( req , res ) => {
2020-08-11 12:24:59 -04:00
channelNameToIds ( req , channelNameFromPath ( req ) , req . query ) . then ( ( { channelIds , options } ) => {
const onSend = streamToHttp ( req , res ) ;
2021-12-25 16:55:06 -05:00
const onEnd = streamHttpEnd ( req , subscriptionHeartbeat ( channelIds ) ) ;
2018-05-21 06:43:38 -04:00
2021-09-26 07:23:28 -04:00
streamFrom ( channelIds , req , onSend , onEnd , options . needsFiltering ) ;
2020-08-11 12:24:59 -04:00
} ) . catch ( err => {
log . verbose ( req . requestId , 'Subscription error:' , err . toString ( ) ) ;
2018-10-11 13:24:43 -04:00
httpNotFound ( res ) ;
2017-11-17 18:16:48 -05:00
} ) ;
} ) ;
2021-03-24 04:37:41 -04:00
const wss = new WebSocket . Server ( { server , verifyClient : wsVerifyClient } ) ;
2017-05-29 12:20:53 -04:00
2020-08-11 12:24:59 -04:00
/ * *
* @ typedef StreamParams
* @ property { string } [ tag ]
* @ property { string } [ list ]
* @ property { string } [ only _media ]
* /
2021-09-26 07:23:28 -04:00
/ * *
* @ param { any } req
2023-04-29 20:29:54 -04:00
* @ returns { string [ ] }
2021-09-26 07:23:28 -04:00
* /
const channelsForUserStream = req => {
const arr = [ ` timeline: ${ req . accountId } ` ] ;
if ( isInScope ( req , [ 'crypto' ] ) && req . deviceId ) {
arr . push ( ` timeline: ${ req . accountId } : ${ req . deviceId } ` ) ;
}
if ( isInScope ( req , [ 'read' , 'read:notifications' ] ) ) {
arr . push ( ` timeline: ${ req . accountId } :notifications ` ) ;
}
return arr ;
} ;
2022-07-13 09:03:28 -04:00
/ * *
* See app / lib / ascii _folder . rb for the canon definitions
* of these constants
* /
const NON _ASCII _CHARS = 'ÀÁÂÃÄÅàáâãäåĀāĂ㥹ÇçĆćĈĉĊċČčÐðĎďĐđÈÉÊËèéêëĒēĔĕĖėĘęĚěĜĝĞğĠġĢģĤĥĦħÌÍÎÏìíîïĨĩĪīĬĭĮįİıĴĵĶķĸĹĺĻļĽľĿŀŁłÑñŃńŅņŇňʼnŊŋÒÓÔÕÖØòóôõöøŌōŎŏŐőŔŕŖŗŘřŚśŜŝŞşŠšſŢţŤťŦŧÙÚÛÜùúûüŨũŪūŬŭŮůŰűŲųŴŵÝýÿŶŷŸŹźŻżŽž' ;
const EQUIVALENT _ASCII _CHARS = 'AAAAAAaaaaaaAaAaAaCcCcCcCcCcDdDdDdEEEEeeeeEeEeEeEeEeGgGgGgGgHhHhIIIIiiiiIiIiIiIiIiJjKkkLlLlLlLlLlNnNnNnNnnNnOOOOOOooooooOoOoOoRrRrRrSsSsSsSssTtTtTtUUUUuuuuUuUuUuUuUuUuWwYyyYyYZzZzZz' ;
/ * *
* @ param { string } str
2023-04-29 20:29:54 -04:00
* @ returns { string }
2022-07-13 09:03:28 -04:00
* /
const foldToASCII = str => {
const regex = new RegExp ( NON _ASCII _CHARS . split ( '' ) . join ( '|' ) , 'g' ) ;
return str . replace ( regex , match => {
const index = NON _ASCII _CHARS . indexOf ( match ) ;
return EQUIVALENT _ASCII _CHARS [ index ] ;
} ) ;
} ;
/ * *
* @ param { string } str
2023-04-29 20:29:54 -04:00
* @ returns { string }
2022-07-13 09:03:28 -04:00
* /
const normalizeHashtag = str => {
return foldToASCII ( str . normalize ( 'NFKC' ) . toLowerCase ( ) ) . replace ( /[^\p{L}\p{N}_\u00b7\u200c]/gu , '' ) ;
} ;
2020-08-11 12:24:59 -04:00
/ * *
* @ param { any } req
* @ param { string } name
* @ param { StreamParams } params
2023-04-29 20:29:54 -04:00
* @ returns { Promise . < { channelIds : string [ ] , options : { needsFiltering : boolean } } > }
2020-08-11 12:24:59 -04:00
* /
const channelNameToIds = ( req , name , params ) => new Promise ( ( resolve , reject ) => {
2021-12-25 16:55:06 -05:00
switch ( name ) {
2017-05-29 12:20:53 -04:00
case 'user' :
2020-08-11 12:24:59 -04:00
resolve ( {
2021-09-26 07:23:28 -04:00
channelIds : channelsForUserStream ( req ) ,
options : { needsFiltering : false } ,
2020-08-11 12:24:59 -04:00
} ) ;
2020-06-02 13:24:53 -04:00
2017-06-03 14:50:53 -04:00
break ;
case 'user:notification' :
2020-08-11 12:24:59 -04:00
resolve ( {
2021-09-26 07:23:28 -04:00
channelIds : [ ` timeline: ${ req . accountId } :notifications ` ] ,
options : { needsFiltering : false } ,
2020-08-11 12:24:59 -04:00
} ) ;
2017-05-29 12:20:53 -04:00
break ;
case 'public' :
2020-08-11 12:24:59 -04:00
resolve ( {
channelIds : [ 'timeline:public' ] ,
2021-09-26 07:23:28 -04:00
options : { needsFiltering : true } ,
2020-08-11 12:24:59 -04:00
} ) ;
2017-05-29 12:20:53 -04:00
break ;
case 'public:local' :
2020-08-11 12:24:59 -04:00
resolve ( {
channelIds : [ 'timeline:public:local' ] ,
2021-09-26 07:23:28 -04:00
options : { needsFiltering : true } ,
2020-08-11 12:24:59 -04:00
} ) ;
2017-05-29 12:20:53 -04:00
break ;
2020-05-10 04:36:18 -04:00
case 'public:remote' :
2020-08-11 12:24:59 -04:00
resolve ( {
channelIds : [ 'timeline:public:remote' ] ,
2021-09-26 07:23:28 -04:00
options : { needsFiltering : true } ,
2020-08-11 12:24:59 -04:00
} ) ;
2020-05-10 04:36:18 -04:00
break ;
2018-05-21 06:43:38 -04:00
case 'public:media' :
2020-08-11 12:24:59 -04:00
resolve ( {
channelIds : [ 'timeline:public:media' ] ,
2021-09-26 07:23:28 -04:00
options : { needsFiltering : true } ,
2020-08-11 12:24:59 -04:00
} ) ;
2018-05-21 06:43:38 -04:00
break ;
case 'public:local:media' :
2020-08-11 12:24:59 -04:00
resolve ( {
channelIds : [ 'timeline:public:local:media' ] ,
2021-09-26 07:23:28 -04:00
options : { needsFiltering : true } ,
2020-08-11 12:24:59 -04:00
} ) ;
2018-05-21 06:43:38 -04:00
break ;
2020-05-10 04:36:18 -04:00
case 'public:remote:media' :
2020-08-11 12:24:59 -04:00
resolve ( {
channelIds : [ 'timeline:public:remote:media' ] ,
2021-09-26 07:23:28 -04:00
options : { needsFiltering : true } ,
2020-08-11 12:24:59 -04:00
} ) ;
2020-05-10 04:36:18 -04:00
break ;
2018-04-18 07:09:06 -04:00
case 'direct' :
2020-08-11 12:24:59 -04:00
resolve ( {
channelIds : [ ` timeline:direct: ${ req . accountId } ` ] ,
2021-09-26 07:23:28 -04:00
options : { needsFiltering : false } ,
2020-08-11 12:24:59 -04:00
} ) ;
2018-04-18 07:09:06 -04:00
break ;
2017-05-29 12:20:53 -04:00
case 'hashtag' :
2020-08-11 12:24:59 -04:00
if ( ! params . tag || params . tag . length === 0 ) {
reject ( 'No tag for stream provided' ) ;
} else {
resolve ( {
2022-07-13 09:03:28 -04:00
channelIds : [ ` timeline:hashtag: ${ normalizeHashtag ( params . tag ) } ` ] ,
2021-09-26 07:23:28 -04:00
options : { needsFiltering : true } ,
2020-08-11 12:24:59 -04:00
} ) ;
2018-10-11 13:24:43 -04:00
}
2017-05-29 12:20:53 -04:00
break ;
case 'hashtag:local' :
2020-08-11 12:24:59 -04:00
if ( ! params . tag || params . tag . length === 0 ) {
reject ( 'No tag for stream provided' ) ;
} else {
resolve ( {
2022-07-13 09:03:28 -04:00
channelIds : [ ` timeline:hashtag: ${ normalizeHashtag ( params . tag ) } :local ` ] ,
2021-09-26 07:23:28 -04:00
options : { needsFiltering : true } ,
2020-08-11 12:24:59 -04:00
} ) ;
2018-10-11 13:24:43 -04:00
}
2017-05-29 12:20:53 -04:00
break ;
2017-11-17 18:16:48 -05:00
case 'list' :
2020-08-11 12:24:59 -04:00
authorizeListAccess ( params . list , req ) . then ( ( ) => {
resolve ( {
channelIds : [ ` timeline:list: ${ params . list } ` ] ,
2021-09-26 07:23:28 -04:00
options : { needsFiltering : false } ,
2020-08-11 12:24:59 -04:00
} ) ;
} ) . catch ( ( ) => {
reject ( 'Not authorized to stream this list' ) ;
2017-11-17 18:16:48 -05:00
} ) ;
2020-08-11 12:24:59 -04:00
2017-11-17 18:16:48 -05:00
break ;
2017-05-29 12:20:53 -04:00
default :
2020-08-11 12:24:59 -04:00
reject ( 'Unknown stream type' ) ;
}
} ) ;
/ * *
* @ param { string } channelName
* @ param { StreamParams } params
2023-04-29 20:29:54 -04:00
* @ returns { string [ ] }
2020-08-11 12:24:59 -04:00
* /
const streamNameFromChannelName = ( channelName , params ) => {
if ( channelName === 'list' ) {
return [ channelName , params . list ] ;
} else if ( [ 'hashtag' , 'hashtag:local' ] . includes ( channelName ) ) {
return [ channelName , params . tag ] ;
} else {
return [ channelName ] ;
}
} ;
/ * *
* @ typedef WebSocketSession
* @ property { any } socket
* @ property { any } request
2023-08-04 10:11:30 -04:00
* @ property { Object . < string , { channelName : string , listener : SubscriptionListener , stopHeartbeat : function ( ) : void } > } subscriptions
2020-08-11 12:24:59 -04:00
* /
/ * *
* @ param { WebSocketSession } session
* @ param { string } channelName
* @ param { StreamParams } params
2023-08-04 10:11:30 -04:00
* @ returns { void }
2020-08-11 12:24:59 -04:00
* /
2023-08-04 10:11:30 -04:00
const subscribeWebsocketToChannel = ( { socket , request , subscriptions } , channelName , params ) => {
2021-12-25 16:55:06 -05:00
checkScopes ( request , channelName ) . then ( ( ) => channelNameToIds ( request , channelName , params ) ) . then ( ( {
channelIds ,
options ,
} ) => {
2020-08-11 12:24:59 -04:00
if ( subscriptions [ channelIds . join ( ';' ) ] ) {
return ;
}
2021-12-25 16:55:06 -05:00
const onSend = streamToWs ( request , socket , streamNameFromChannelName ( channelName , params ) ) ;
2020-08-11 12:24:59 -04:00
const stopHeartbeat = subscriptionHeartbeat ( channelIds ) ;
2021-12-25 16:55:06 -05:00
const listener = streamFrom ( channelIds , request , onSend , undefined , options . needsFiltering ) ;
2020-08-11 12:24:59 -04:00
2023-08-04 10:11:30 -04:00
connectedChannels . labels ( { type : 'websocket' , channel : channelName } ) . inc ( ) ;
2020-08-11 12:24:59 -04:00
subscriptions [ channelIds . join ( ';' ) ] = {
2023-08-04 10:11:30 -04:00
channelName ,
2020-08-11 12:24:59 -04:00
listener ,
stopHeartbeat ,
} ;
} ) . catch ( err => {
log . verbose ( request . requestId , 'Subscription error:' , err . toString ( ) ) ;
socket . send ( JSON . stringify ( { error : err . toString ( ) } ) ) ;
} ) ;
2023-08-04 10:11:30 -04:00
}
const removeSubscription = ( subscriptions , channelIds , request ) => {
log . verbose ( request . requestId , ` Ending stream from ${ channelIds . join ( ', ' ) } for ${ request . accountId } ` ) ;
const subscription = subscriptions [ channelIds . join ( ';' ) ] ;
if ( ! subscription ) {
return ;
}
channelIds . forEach ( channelId => {
unsubscribe ( ` ${ redisPrefix } ${ channelId } ` , subscription . listener ) ;
} ) ;
connectedChannels . labels ( { type : 'websocket' , channel : subscription . channelName } ) . dec ( ) ;
subscription . stopHeartbeat ( ) ;
delete subscriptions [ channelIds . join ( ';' ) ] ;
}
2020-08-11 12:24:59 -04:00
/ * *
* @ param { WebSocketSession } session
* @ param { string } channelName
* @ param { StreamParams } params
2023-08-04 10:11:30 -04:00
* @ returns { void }
2020-08-11 12:24:59 -04:00
* /
2023-08-04 10:11:30 -04:00
const unsubscribeWebsocketFromChannel = ( { socket , request , subscriptions } , channelName , params ) => {
2020-08-11 12:24:59 -04:00
channelNameToIds ( request , channelName , params ) . then ( ( { channelIds } ) => {
2023-08-04 10:11:30 -04:00
removeSubscription ( subscriptions , channelIds , request ) ;
} ) . catch ( err => {
log . verbose ( request . requestId , 'Unsubscribe error:' , err ) ;
2020-08-11 12:24:59 -04:00
2023-08-04 10:11:30 -04:00
// If we have a socket that is alive and open still, send the error back to the client:
// FIXME: In other parts of the code ws === socket
if ( socket . isAlive && socket . readyState === socket . OPEN ) {
socket . send ( JSON . stringify ( { error : "Error unsubscribing from channel" } ) ) ;
2020-08-11 12:24:59 -04:00
}
} ) ;
2023-08-04 10:11:30 -04:00
}
2020-08-11 12:24:59 -04:00
2020-11-12 17:05:24 -05:00
/ * *
* @ param { WebSocketSession } session
* /
const subscribeWebsocketToSystemChannel = ( { socket , request , subscriptions } ) => {
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
const accessTokenChannelId = ` timeline:access_token: ${ request . accessTokenId } ` ;
const systemChannelId = ` timeline:system: ${ request . accountId } ` ;
2020-11-12 17:05:24 -05:00
const listener = createSystemMessageListener ( request , {
2021-12-25 16:55:06 -05:00
onKill ( ) {
2020-11-12 17:05:24 -05:00
socket . close ( ) ;
} ,
} ) ;
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
subscribe ( ` ${ redisPrefix } ${ accessTokenChannelId } ` , listener ) ;
2020-11-12 17:05:24 -05:00
subscribe ( ` ${ redisPrefix } ${ systemChannelId } ` , listener ) ;
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
subscriptions [ accessTokenChannelId ] = {
2023-08-04 10:11:30 -04:00
channelName : 'system' ,
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 03:42:13 -04:00
listener ,
stopHeartbeat : ( ) => {
} ,
} ;
2020-11-12 17:05:24 -05:00
subscriptions [ systemChannelId ] = {
2023-08-04 10:11:30 -04:00
channelName : 'system' ,
2020-11-12 17:05:24 -05:00
listener ,
2021-12-25 16:55:06 -05:00
stopHeartbeat : ( ) => {
} ,
2020-11-12 17:05:24 -05:00
} ;
2023-08-04 10:11:30 -04:00
connectedChannels . labels ( { type : 'websocket' , channel : 'system' } ) . inc ( 2 ) ;
2020-11-12 17:05:24 -05:00
} ;
2020-08-11 12:24:59 -04:00
/ * *
* @ param { string | string [ ] } arrayOrString
2023-04-29 20:29:54 -04:00
* @ returns { string }
2020-08-11 12:24:59 -04:00
* /
const firstParam = arrayOrString => {
if ( Array . isArray ( arrayOrString ) ) {
return arrayOrString [ 0 ] ;
} else {
return arrayOrString ;
}
} ;
wss . on ( 'connection' , ( ws , req ) => {
const location = url . parse ( req . url , true ) ;
2021-12-25 16:55:06 -05:00
req . requestId = uuid . v4 ( ) ;
2020-08-11 12:24:59 -04:00
req . remoteAddress = ws . _socket . remoteAddress ;
2021-03-24 04:37:41 -04:00
ws . isAlive = true ;
ws . on ( 'pong' , ( ) => {
ws . isAlive = true ;
} ) ;
2023-08-04 10:11:30 -04:00
connectedClients . labels ( { type : 'websocket' } ) . inc ( ) ;
2020-08-11 12:24:59 -04:00
/ * *
* @ type { WebSocketSession }
* /
const session = {
socket : ws ,
request : req ,
subscriptions : { } ,
} ;
const onEnd = ( ) => {
2023-08-04 10:11:30 -04:00
const subscriptions = Object . keys ( session . subscriptions ) ;
2020-08-11 12:24:59 -04:00
2023-08-04 10:11:30 -04:00
subscriptions . forEach ( channelIds => {
removeSubscription ( session . subscriptions , channelIds . split ( ';' ) , req )
} ) ;
2020-08-11 12:24:59 -04:00
2023-08-04 10:11:30 -04:00
// ensure garbage collection:
session . socket = null ;
session . request = null ;
session . subscriptions = { } ;
2020-08-11 12:24:59 -04:00
2023-08-04 10:11:30 -04:00
connectedClients . labels ( { type : 'websocket' } ) . dec ( ) ;
2020-08-11 12:24:59 -04:00
} ;
ws . on ( 'close' , onEnd ) ;
ws . on ( 'error' , onEnd ) ;
2023-06-09 13:29:16 -04:00
ws . on ( 'message' , ( data , isBinary ) => {
if ( isBinary ) {
2023-06-10 12:24:37 -04:00
log . warn ( 'socket' , 'Received binary data, closing connection' ) ;
2023-06-09 13:29:16 -04:00
ws . close ( 1003 , 'The mastodon streaming server does not support binary messages' ) ;
return ;
}
const message = data . toString ( 'utf8' ) ;
const json = parseJSON ( message , session . request ) ;
2020-11-12 17:05:24 -05:00
2020-09-22 09:30:41 -04:00
if ( ! json ) return ;
2020-11-12 17:05:24 -05:00
2020-09-22 09:30:41 -04:00
const { type , stream , ... params } = json ;
2020-08-11 12:24:59 -04:00
if ( type === 'subscribe' ) {
subscribeWebsocketToChannel ( session , firstParam ( stream ) , params ) ;
} else if ( type === 'unsubscribe' ) {
2020-11-23 11:35:14 -05:00
unsubscribeWebsocketFromChannel ( session , firstParam ( stream ) , params ) ;
2020-08-11 12:24:59 -04:00
} else {
// Unknown action type
}
} ) ;
2020-11-12 17:05:24 -05:00
subscribeWebsocketToSystemChannel ( session ) ;
2020-08-11 12:24:59 -04:00
if ( location . query . stream ) {
subscribeWebsocketToChannel ( session , firstParam ( location . query . stream ) , location . query ) ;
2017-05-29 12:20:53 -04:00
}
2017-05-20 11:31:47 -04:00
} ) ;
2017-02-03 18:34:31 -05:00
2021-03-24 04:37:41 -04:00
setInterval ( ( ) => {
wss . clients . forEach ( ws => {
if ( ws . isAlive === false ) {
ws . terminate ( ) ;
return ;
}
ws . isAlive = false ;
2021-05-02 08:30:26 -04:00
ws . ping ( '' , false ) ;
2021-03-24 04:37:41 -04:00
} ) ;
} , 30000 ) ;
2017-05-28 10:25:26 -04:00
2018-10-19 20:25:25 -04:00
attachServerWithConfig ( server , address => {
2023-04-26 05:37:51 -04:00
log . warn ( ` Streaming API now listening on ${ address } ` ) ;
2018-10-19 20:25:25 -04:00
} ) ;
2017-04-21 13:24:31 -04:00
2017-05-28 10:25:26 -04:00
const onExit = ( ) => {
2017-05-20 11:31:47 -04:00
server . close ( ) ;
2017-07-07 14:01:00 -04:00
process . exit ( 0 ) ;
2017-05-28 10:25:26 -04:00
} ;
const onError = ( err ) => {
log . error ( err ) ;
2017-12-12 14:19:33 -05:00
server . close ( ) ;
process . exit ( 0 ) ;
2017-05-28 10:25:26 -04:00
} ;
process . on ( 'SIGINT' , onExit ) ;
process . on ( 'SIGTERM' , onExit ) ;
process . on ( 'exit' , onExit ) ;
2017-12-12 14:19:33 -05:00
process . on ( 'uncaughtException' , onError ) ;
2017-05-28 10:25:26 -04:00
} ;
2020-08-11 12:24:59 -04:00
/ * *
* @ param { any } server
* @ param { function ( string ) : void } [ onSuccess ]
* /
2018-10-19 20:25:25 -04:00
const attachServerWithConfig = ( server , onSuccess ) => {
if ( process . env . SOCKET || process . env . PORT && isNaN ( + process . env . PORT ) ) {
server . listen ( process . env . SOCKET || process . env . PORT , ( ) => {
if ( onSuccess ) {
2018-10-21 10:41:33 -04:00
fs . chmodSync ( server . address ( ) , 0o666 ) ;
2018-10-19 20:25:25 -04:00
onSuccess ( server . address ( ) ) ;
}
} ) ;
} else {
2019-07-14 23:56:35 -04:00
server . listen ( + process . env . PORT || 4000 , process . env . BIND || '127.0.0.1' , ( ) => {
2018-10-19 20:25:25 -04:00
if ( onSuccess ) {
onSuccess ( ` ${ server . address ( ) . address } : ${ server . address ( ) . port } ` ) ;
}
} ) ;
}
} ;
2023-04-26 05:37:51 -04:00
startServer ( ) ;