Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2023-02-27T11:48:36Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2461Converting URL auth to use string renderer.2023-02-27T11:48:36ZPhilipp SchafftConverting URL auth to use string renderer.Currently the URL auth backend builds it's POST data itself. This should be migrated to use string renderer. The code from URL events can be used as a template.Currently the URL auth backend builds it's POST data itself. This should be migrated to use string renderer. The code from URL events can be used as a template.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2435URL Auth does not post good port2022-04-07T17:32:54ZRa LawaURL Auth does not post good portHi,
URL Auth always posts the first listen-socket port configured in icecast.xml. When both http (port 80) and https (port 443) are enabled, url auth always send port=80 in the post request.
I think, it should send port=80 when the cli...Hi,
URL Auth always posts the first listen-socket port configured in icecast.xml. When both http (port 80) and https (port 443) are enabled, url auth always send port=80 in the post request.
I think, it should send port=80 when the client uses an http request and 443 when it uses an https request.
For url redirection, this would help to produce an url which depends on method used by the client. Redirection to an https url when client uses an https url and http otherwise.
Currently I use an other method to know which method is used. I patched url_add_client to send also tlsmode to the post request.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2396Unifiy <xsl:output>-settings for web/ and admin/2020-10-09T16:38:28ZPhilipp SchafftUnifiy <xsl:output>-settings for web/ and admin/`<xsl:output>`-settings must match web/ and admin/ as they share some templates.`<xsl:output>`-settings must match web/ and admin/ as they share some templates.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2361Remove RAWURI values from URL auth2018-11-27T09:57:57ZPhilipp SchafftRemove RAWURI values from URL authCurrently the URL auth system transmits the RAWURI value if available as "mount"-parameter. This includes query strings. However it does not include POST parameters (therefore is inconsistent).
This should be deprecated and only the res...Currently the URL auth system transmits the RAWURI value if available as "mount"-parameter. This includes query strings. However it does not include POST parameters (therefore is inconsistent).
This should be deprecated and only the resource the user connected to should be included.
It must be discussed if it should transmit the original resource name (before `<resource>` processing) if they differ.
See also: #2360.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2360Document and define query string and POST parameters2022-03-11T12:47:10ZPhilipp SchafftDocument and define query string and POST parametersThe currently existing parameters should be documented.
Also it should be one or more or a prefix for custom parameters be defined for user specific data.
* The value(s) should be send to logging,
* the value(s) should be send to auth,
...The currently existing parameters should be documented.
Also it should be one or more or a prefix for custom parameters be defined for user specific data.
* The value(s) should be send to logging,
* the value(s) should be send to auth,
* the value(s) may be send to (fast)events.
A single value like 'token' or 'etoken' (e ➔ external) would be easy and secure to implement. However a user that needs multiple values must encode them into a single value themselfs in that case.
On the other paw a prefix could be defined (such as 'e-', e ➔ external) that is considered 'safe' (as in not used by Icecast or any future version) even if not used. This would allow future extension at some point.
currently the following parameters are universal:
* omode
* mount
The admin/-interface uses more parameters.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2358Improve Icecast's logging of developer only messages2019-04-23T13:54:32ZPhilipp SchafftImprove Icecast's logging of developer only messagesCurrently Icecast logs many details that are only of interest to developers. Those lines "spam" the error log.
There should be a way to disable those messages. This could happen using the well-known DEBUG macro OR by adding another log ...Currently Icecast logs many details that are only of interest to developers. Those lines "spam" the error log.
There should be a way to disable those messages. This could happen using the well-known DEBUG macro OR by adding another log level or log flag (as those messages may themself have different log levels as per their logic).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2350Common matching frame work2019-01-22T06:31:38ZPhilipp SchafftCommon matching frame workCurrently the following parts of Icecast do client and client-status matching:
* `<resource>`
* `<role>` (auth)
* `<header>` (child of `<http-headers>`)
* `<event>` (child of `<event-bindings>`)
We also expect the following new users so...Currently the following parts of Icecast do client and client-status matching:
* `<resource>`
* `<role>` (auth)
* `<header>` (child of `<http-headers>`)
* `<event>` (child of `<event-bindings>`)
We also expect the following new users soon:
* `<acl>` (child of `<auth>`)
A common framework should be written to allow implementing matching.
This depends on #2349 (for refobject).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2345For close-only-review2018-11-09T07:32:50ZPhilipp SchafftFor close-only-reviewThe following tasks should be closed as they are or re-opened for review as per comment.
* [x] #2085
* [x] #2057
* [x] #2017
* [x] #2171
* [x] #1195
* [x] #1296The following tasks should be closed as they are or re-opened for review as per comment.
* [x] #2085
* [x] #2057
* [x] #2017
* [x] #2171
* [x] #1195
* [x] #1296Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2333Make playlist generation consistent2020-10-11T16:28:01ZMarvin ScholzMake playlist generation consistentCurrently all playlist formats are generated using XSLT, but m3u is generated in C code. This should be done consistent, either all as XSLT or all in C code.
Opinions which way will be better welcome!Currently all playlist formats are generated using XSLT, but m3u is generated in C code. This should be done consistent, either all as XSLT or all in C code.
Opinions which way will be better welcome!https://gitlab.xiph.org/xiph/icecast-server/-/issues/2110Timer-based functionalities should use single timer thread2022-05-16T23:03:32ZMarvin ScholzTimer-based functionalities should use single timer thread>all timer-based functionality (yp updates, slave/relay checks) should have a
>single timer thread which dispatches events through the normal event
>mechanism (to worker threads from the main pool). This will reduce the
>extraneous threa...>all timer-based functionality (yp updates, slave/relay checks) should have a
>single timer thread which dispatches events through the normal event
>mechanism (to worker threads from the main pool). This will reduce the
>extraneous thread count.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2109Abstract admin functionality to set of commands and handlers2020-10-15T09:20:39ZMarvin ScholzAbstract admin functionality to set of commands and handlers>abstract all admin functionality to a set of commands, and command handlers.
>
>Make /admin/* just parse according to a set of rules, and dispatch generic
>commands through that.
>
>Use this for alternative admin interfaces (GUI? telnet...>abstract all admin functionality to a set of commands, and command handlers.
>
>Make /admin/* just parse according to a set of rules, and dispatch generic
>commands through that.
>
>Use this for alternative admin interfaces (GUI? telnet interface?)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2108Registrable URL handlers in connection.c instead of hardcoded list2018-07-16T09:09:26ZMarvin ScholzRegistrable URL handlers in connection.c instead of hardcoded listSuggested in TODO
>general registerable url-handlers in connection.c rather than hard-coded list
>(already getting unmaintainable)Suggested in TODO
>general registerable url-handlers in connection.c rather than hard-coded list
>(already getting unmaintainable)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2058[PATCH] Replace logging macros2018-03-06T12:49:47ZMarvin Scholz[PATCH] Replace logging macrosReplace the old logging macros with variadic argument macros.
`ERROR0`, `ERROR1`, `ERROR2`, `ERROR3`, `ERROR4` are replaced with `LOG_ERROR`
`WARN0`, `WARN1`, `WARN2`, `WARN3` are replaced with `LOG_WARN`
`INFO0`, `INFO1`, `INFO2`, `INF...Replace the old logging macros with variadic argument macros.
`ERROR0`, `ERROR1`, `ERROR2`, `ERROR3`, `ERROR4` are replaced with `LOG_ERROR`
`WARN0`, `WARN1`, `WARN2`, `WARN3` are replaced with `LOG_WARN`
`INFO0`, `INFO1`, `INFO2`, `INFO3` are replaced with `LOG_INFO`
`DEBUG0`, `DEBUG1`, `DEBUG2`, `DEBUG3`, `DEBUG4` are replaced with `LOG_DEBUG`
Additionally a bit formatting was done, to match common c code style (only where it really shouted for attention, while looking through the files)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/738Errorcode when client wants to connect to "full" mountpoint should be changed2020-10-15T13:51:17ZrobeErrorcode when client wants to connect to "full" mountpoint should be changedHi,
the errorcode that clients receive when they want to connect to a mountpoint which has reached its maxlisteners limit should be changed from the current "404 File Not Found" to something more meaningful, since this is the same error...Hi,
the errorcode that clients receive when they want to connect to a mountpoint which has reached its maxlisteners limit should be changed from the current "404 File Not Found" to something more meaningful, since this is the same errorcode that gets returned when the requested mountpoint doesn't exist.
A possible solution to this would be returning 403 with a customized reason phrase like "Mountpoint full" (or similar) in the header (since this is the only thing (if any) that gets forwarded to the user with most clients). The HTTP 1.1 RFC (#2616) allows this:
6.1.1:
[..]
The individual values of the numeric status codes defined for
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only
recommendations -- they MAY be replaced by local equivalents without
affecting the protocol.
[..]Philipp SchafftPhilipp Schafft