Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • Icecast-Server Icecast-Server
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 117
    • Issues 117
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 5
    • Merge requests 5
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Terraform modules
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • External wiki
    • External wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Xiph.OrgXiph.Org
  • Icecast-ServerIcecast-Server
  • Issues
  • #2119
Closed
Open
Issue created Dec 10, 2014 by Philipp Schafft@phschafft🦁Maintainer

Filter based on User Agent

There is <allow-ip> and <deny-ip> already. Someone was asking me for a way to filter clients based on User Agents.

I would suggest to implement this as a role-type. This should allow matching on all headers and maybe on other kinds of client data as well. The module would return NOMATCH on no match or FAILED on match on deny list. Behaviour on pass should maybe be documented. Defaulting to NOMATCH to continue with the processing of other <role>s.

Some technical background: In contrast to the <allow-ip> and <deny-ip> this check can only happen after the client request has been parsed as it depends on data of exactly this client request. This makes it less suitable for (D)DoS protection in general. It should be considered to use some kind of firewalling of fail2ban to protect against such attacks.

Pros of implementing it the way described above:

  • It would match the internal schemata and wouldn't be another alien.
  • It could be extended to universally match any configured attributes of the client object.
  • Integrates well into usage together with other <role>s. E.g. to allow some role access but deny others access depending on this module (admin can always go, listeners only if user agent matches).
  • Rejects the client with a 401 according to the standard. Contra:
  • Is much slower than implementing it in a specific and specific way as it happens in the authentication engine and not in before on rejected clients. Slowdown for passing clients will not be significant.
  • Rejects clients with a standard conforming 401. Does not just drop them.
Edited Nov 10, 2018 by Philipp Schafft
Assignee
Assign to
Time tracking