Some handy features (non-UTF8 charset decoding, webirc header support) #8
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've been using orbited2 for a while now on my own server to run a WebIRC script that connects to my IRC server.
However, this has a few problems:
1 - Some IRC clients do not produce valid UTF-8, crashing any user connected through orbited2.
2 - All users that connect though orbited2 show up as IP address "localhost", effectively making it impossible to ban them.
Problem 1 is fixed by the non-UTF8 charset decoding, turning all incoming data into valid UTF-8.
(Note: The non-UTF8 charset decoding was not added by me, but by a friend of mine: Pol Van Aubel ([email protected]) )
Problem 2 is fixed by the addition of a webirc setting in the config file, allowing people to set a password for the webirc "standard" that deals with solving exactly this problem.
Since my server is IPv6 enabled and apparently webirc has problems with non-IPv4 addresses, I made the webirc command only take the IPv4 part of the IPv6 address if available. This is obviously wrong in the case that the server is not IPv6 enabled, and even more wrong when somebody actually connects over IPv6. To combat this, I also added a "ipv6entry" command, which always takes the valid client address, but assumes the server reading this information understands both IPv4 and IPv6 (see this as the "future proof" version of this command).
I hope you find these additions useful and will add them to the main project!
Speaking of - is this still in active development? Just wondering :-)