Anope.org > General Chat

* Set by ChanServ on

<< < (2/3) > >>

Andromeda:
I'm afraid CrazyCat is right, that boils down to the IRCd not Anope.

I don't think there is any way possible to show the topic set by user even on a developer level without modifying the IRCd to allow "fake nicks" for U:Lined servers which in theory could use any nick to set a topic or send a message.... I also wouldn't recommend this, there are safeguards in place to prevent user abuse.

Unlocking this would allow use of commands such as /os svssay <some fake nick> <chan/user> <message>... which could be pretty neat, but would no doubt be abused on many networks.

There's also no telling what other side effects this could cause... but none the less, there is nothing Anope could do, it's the IRCd.

w00:
thanks for reply..

okay, but how ChanServ can set topic in the "past" date if its
setting it right after join empty channel, then easy can be
used a nick of the user who set topic as it stored in:

info #channel all

[13:37] -ChanServ (services@some.thing)- Last topic: some_topic
[13:37] -ChanServ (services@some.thing)- Topic set by: w00

should be a routines to pass this info too..
or make chanserv rename itself for a moment of setting topic for a nickname
from 'topic set by:'


PS. locked topic mode not interesting.

lets modify ircd then... please save my time and tell me where to dig next..

i not remember what happening during splits and how info synched in this
situation (topic set by ircd.stealth.net.. ? topic date?), or each server will
have their own setting until somebody will set new topic.. or maybe splits
not a case nowadays, as i am talking about 90-x..

tnx

Andromeda:
I'm not entirely sure what you're trying to say here, but I think I get the gist of it all...

Simply put, you could modify the IRCd, but no, I can't tell you where to dig for how... every IRCd is different, that's why Anope has protocol select in the configuration files so it will send/receive the correct messages... sadly to say, you're on your own with that one.

Honestly I don't see the problem with just letting ChanServ set the topic...
But what you're wanting is for a user to set a topic when that user isn't setting the topic.... it can't be done safely. Basically it would be like me posting this reply on this forum but wanting my name to display as "Administrator"...

IRC protocol is very specific.... for example, with Unreal, the raw protocol for topic would be:

--- Code: ---:source TOPIC #channel nick timestamp :text
--- End code ---

Where source would be the person/service setting the topic. You can't just use *any* source you want, it has to exist within services to do.

Sorry, what you want is realistically not possible.

katsklaw:
Actually, source would be the server sending the data, in this case source = ServerName. Ircds generally have security measures built in to prevent bogus data from being injected. In this case if nick is not from source, it's likely dropped as erronious data.

That said, its possible to write a module to append the setting nick to the end of the topic by TAIL'ing the topic command.

Hope that helps.

Andromeda:

--- Quote from: katsklaw on April 18, 2014, 07:13:50 PM ---Actually, source would be the server sending the data, in this case source = ServerName. Ircds generally have security measures built in to prevent bogus data from being injected. In this case if nick is not from source, it's likely dropped as erronious data.

That said, its possible to write a module to append the setting nick to the end of the topic by TAIL'ing the topic command.

Hope that helps.

--- End quote ---

"source" is the location it came from, it doesn't need to be a server. If you use /topic #test boo, YOU will be the source.

For example:
Self: /topic #Test boo = :Andromeda TOPIC #Test Andromeda 1397845002 :boo
Services: /cs topic set #Test boo = :services.mynetwork.tld TOPIC #Test Andromeda 1397845002 :boo

(Note this syntax is IRCd dependant; and I *did* just verify this to be 100% sure it didn't set source to the server the user was on)

Navigation

[0] Message Index

[#] Next page

[*] Previous page