Limiting the Number of Sessions per User (Anti-Theft)
max-sessions
To prevent users with access to the streams from full restreaming to their servers (for example, for further re-selling), Flussonic Media Server has an ability to limit the number of simultaneously viewed streams. Thus, even after obtaining the access to all streams, the user may only view N streams simultaneously, and attempts to restream all streams will result in nothing.
The limitation is made for each user with his own UserId
and set with authorization.
Details
In order to limit the number of sessions to 2, in the authorization backend the following headers should be set:
X-UserId: some-user-id
X-Max-Sessions: 2
And fields user_id
and max_sessions
via the lua backend, respectively.
If, after such authorization, a user tries to view simultaneously three streams, one of them will be interrupted.
Ban
After a session has been banned, any attempt to reopen it within the period of X-AuthDuration
will be rejected by Flussonic Media Server.
Therefore, if X-AuthDuration: 3600
is specified, and an extra stream is opened, after this stream has been interrupted, it will be impossible to open this stream with the old token for one hour.
After a session has been banned, the next request from client's HLS playlist will receive a 403 Forbidden response. In case of RTSP, RTMP, the HTTP MPEG-TS socket will just be silently closed.
Each banned session is accompanied by a log entry like:
14:58:51.598 <0.391.0> [stream-name] session_limiter:174 Ban session_id: <<"604551981e3e787b897afbaf35bb9f4d168d70b9">> for user_id: <<"8471796306">> and token: <<"5cfb82ecaf56ebfe7ac32a9020c86ef1d231d49e">> due to exceeded session limit
Soft limitation
Some middlewares cannot generate a new token for every new HLS stream request. This behavior may cause problems during switching between streams because sessions for old streams will be marked as excessive and banned.
Exactly for such cases Flussonic Media Server has soft limitation mode for sessions.
Sometimes, interruption does not happen after the first check (time is needed to understand that all sessions are actually being used), but it occurs after the second or the third check. Thus, after extra sessions are opened, they are usually interrupted in 30 to 90 seconds.
If you want to enable this mode, you need to specify the soft_limitation=true
key for the auth
option, for example:
stream foobar {
auth http://localhost:8081/my_auth_script.php soft_limitation=true;
}
The option soft_limitation
can also be set in the UI on the Conifg > Auth page:
X-Unique: true
The X-Unique
header is deprecated, the X-Max-Sessions
described above should be used instead.
X-UserId: some-id
X-Unique: true
is absolutely equivalent to:
X-UserId: some-id
X-Max-Sessions: 1
Besides, if both X-Max-Sessions
and X-Unique
are specified, the X-Max-Sessions
is the priority. This way:
X-UserId: some-id
X-Max-Sessions: 5
X-Unique: true
is equivalent to:
X-UserId: some-id
X-Max-Sessions: 5
Comments on versions
- In version 4.5.5 and above, Flussonic is capable of allowing N number of sessions, rather than just one. (X-Unique: true)
- In versions 4.5.13 and above, the period of session re-check via the backend (
X-AuthDuration
) by default is 180 seconds (3 minutes), instead of 30 seconds. - In version 4.5.15 and above, the
auth_time
returned from lua backend is interpreted as seconds (instead of milliseconds in earlier versions), by analogy withX-AuthDuration
of the http-backend.