Flussonic Media Server documentation

Contents

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.

It 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 additional soft_limitation=true key for the auth option, for example:

stream foobar {
  auth http://localhost:8081/my_auth_script.php soft_limitation=true;
}

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 with X-AuthDuration of the http-backend.