Hello, our TS Live Banner Team has long wanted a few simple changes that could actually be a matter of minutes.
These would be:
I mean it is not intended to have dynamic banners. So I think it’s fair that this is not a thing…
I think comparing IP addresses is not too hard if you really feel that you need dynamic banners.
We are concerned with how to sort a user exactly, e.g you have 5 users in one household who are all on the TS server at the same time, then you have the problem that you cannot know exactly which one based on the IP User is concerned, this is of course also used, but only IP is â– â– â– â–
I had the same problem at a lan party, everyone was suddenly Marc.
This idea could be great, and also doesn’t take much effort. I think a lot of creators can use this^^
Since it’s useful with the client ID to get them.
I can see the use cases for these custom headers but I’m not comfortable with leaking even more internal information like client IDs to third parties.
The current image fetcher operates on the client side and already leaks the client IP address to third parties when loading external images within channel descriptions.
If these headers get added, there needs to be a way to whitelist specific trusted URLs or URL patterns to receive those headers.
You can’t brag about your awesome encryption features but then have the client broadcast internal data out into the world, even if it is just IDs.
And before anyone argues that IDs are not secret:
There is a difference between exchanging essential data between server and client in a controlled environment which is subject to ACLs and the server broadcasting that data out into the world without anyone even thinking about it.
The abuse of privacy and the prosperity of TeamSpeak users is a problem, so I can understand your reasoning about the channel banner.
In relation to the server banner, on the other hand, I think it is quite justified.
I would also do it by default off (only remote address), but the server owner can say, “Hey, okay, nothing, our concept with the fantastic banner that we trust because it comes from ourselves.”.
Nice idea bro
Hey there,
In TeamSpeak3 there is a header being sent that helps identify users viewing the TeamSpeak-Banner. That would also be very nice to have in TeamSpeak5. Should be easy to add and helps servers that are relying on it 
Best regards
Felix
Hello,
The TeamSpeak 5 version does not send any information in the banner query that helps identify the client. TeamSpeak 3 sends the “Teamspeak-Client-Uid” header in the query - is there a chance this could be implemented?
Hello, I would like to suggest adding back the teamspeak-client-uid header to the HTTP request for server banner. I remember this was a thing on TS3, but since TS5 came out this header is no longer present in the request.
It would also be helpful if you add myTeamSpeakID as another header (teamspeak-client-mytsid for example). This way server could generate dynamic images for different clients (client info, stats summary, etc)
Due to privacy concerns we’ve came to the conclusion to remove those requests and don’t plan to bring them back.
Sorry, but I can’t see what is the problem here. Are we talking about the same thing? TS3 has the teamspeak-client-uid header to this day and I can’t understand how is this a privacy concern. As a server administrator I can already see the UID and MyTSId of any user that is connected to the server (for example using server query). So in this situation i would like to set the URL of server banner to my own web server that would generate custom banner - different for each of the connected clients.
If request headers are problematic (once again, this is still working on TS3) maybe you can add some variables that server admin could add to the URL. For example:
%uid% - UID of the client%mytsid% - MyTSId of the clientExample Server Banner URL using these variables:
https://my-server.com/dynamic-banner?uid=%uid%&mytsid=%mytsid%
In this scenario none of the proposed HTTP headers are sent and server admin can add additional parameters to the URL if they are needed - if not then they don’t need to be passed in the URL
All the security concerns could be negated by simply not using uid/mytsid but just the CID. It can still be mapped to a specific user through e.g. a query account, but does not allow to draw conclusions about the user without also having access to the server itself.
But this issue was raised multiple times in the past to no avail…
HI
I am currently working with the host banner system and ran into a technical limitation regarding user identification.
The banner is requested as a simple HTTP image request. On the server side, only the IP address of this request is available. The problem is that this IP does not reliably represent the actual connection of the TeamSpeak client.
In dual stack environments the following situation happens:
[User Client]
|
| (TeamSpeak connection via IPv4)
v
[TS Server]
[User Client]
|
| (Banner HTTP request via IPv6)
v
[Web Server / banner.php]
So the same user can:
connect to the TeamSpeak server using IPv4
but load the banner using IPv6
Or the other way around.
Because of this mismatch, it is not possible to reliably assign a banner request to a specific user. The banner system and the actual client connection are technically separated and do not share any identifier.
Even when only a single protocol is used (for example only IPv4), identification is still not reliable. Multiple users can share the same IPv4 address (for example due to NAT). In my implementation, I already handle this by falling back to a generic banner if multiple users match the same IP.
However, this shows that IP-based matching is not a robust solution in general.
Current limitations:
Only the request IP is visible in web request (banner)
IPv4 and IPv6 cannot be reliably linked to the same user
Multiple users may share the same IP (especially IPv4)
No client unique ID or database ID is available
The banner URL is static and not user-specific
Suggested improvement:
It would be very helpful if the banner request could include a minimal client identifier, for example:
client unique ID
client database ID
Possible ways to provide this:
via HTTP headers
or as parameters in the banner request
With such an identifier, it would be possible to reliably map banner requests to users, even in IPv4 / IPv6 mixed environments and shared IP scenarios.
This would enable:
user specific banner content
more accurate statistics
better integrations for server administrators
Thank you for your time and consideration.
i have some times 4 IPs with over 10 users per ip…
