Entries moved from the services TODO list that have long since been fixed:
- Header and Footer to /msg nickserv help - Fixed
- email should not be publicly available in msg nickserv info foo - Fixed
Implement the services central language thing (to prevent things like 22:44 [testnet] -NickServ- Insufficient params. Got %d need %d) - Done. Please now report any "%"s appearing in output.
- /msg help drop: should not display "Usage: REGISTER" at the top. Language file problem. - Fixed
- reopen all logfiles on HUP
- dropping a nickname should -R the user of that nick
- sudo command (to let services admin bypass other checks and screw up innocent people's nicks)
ctcp support NickServ(services@newservices.testnet.oftc.net)- Unknown command APING, /msg NickServ HELP for help.
drop gives bad usage:
Thu 20:26:16 <weasel-neutron> drop Thu 20:26:16 -NickServ(services@newservices.testnet.oftc.net)- Insufficient paramters. Expected at least 1, got 0. Thu 20:26:19 <weasel-neutron> help drop Thu 20:26:19 -NickServ(services@newservices.testnet.oftc.net)- Usage: REGISTER
- drop currently works as any user that is identified.
- currently services dies or shuts down when it is squit from the server it's linked to. it really should try to reconnect - maybe add some timers and counts to this, as if it fails to connect it wont try again.
info <nick> should should say "Is currently online [as <nick>]" (the as <nick> is in case of linked nicknames) when a user is online. probably near the "last quit message"
- identifying an already identified nick should say 'already identified'
- should not. it should be completely silent. -- weasel
- if i give a command, i would like some feedback on it :), it's frustrating if you dont get anything, it's like it's not working -- cemc
- ah, you mean identifying with the IDENTIFY command. yes, I agree that this should get feedback.
- You get perfectly good feedback, it tells you it identified you. Being able to reidentify has its uses(applying cloaks, etc). - Not a bug -- cryogen
- ah, you mean identifying with the IDENTIFY command. yes, I agree that this should get feedback.
- if i give a command, i would like some feedback on it :), it's frustrating if you dont get anything, it's like it's not working -- cemc
- should not. it should be completely silent. -- weasel
- email addresses are visible to everyone. -- w
- register should at least do some verification of email address syntax. Like requiring an @. -w -- we check for a '@' now, better than nothing
too many arguments should be an error too: -w
Sun 19:31:25 <weasel> register x y z a b c Sun 19:31:25 -NickServ(services@newservices.testnet.oftc.net)- Nickname weasel has been registered. Sun 19:31:04 <weasel> drop t1 Sun 19:31:04 -NickServ(services@newservices.testnet.oftc.net)- Nickname weasel has been DROPped.
- I disagree, it is dangerous in the case of drop, but if we switch to a 2 stage process that gets fixed. As long as your arguments match the validation of the command, it should get executed. -- c
- Too many arguments never must validate then. If there are unused arguments something is wrong with the command. It should not get executed.
- I disagree, it is dangerous in the case of drop, but if we switch to a 2 stage process that gets fixed. As long as your arguments match the validation of the command, it should get executed. -- c
- identify help may have wrong argument order in nickserv -w
- "weasel is currently online from nick weasel" in nickserv info: the "from nick weasel" should probably not be printed if both nicks are the same -w -- Fixed but slave nicks dont display
- Can we not store quits due to netsplits for last quit time/message. Do we want that? It means that maybe we would need a last seen that's different from last quit, because they might go away on the other side of a split. -- weasel
Or we could just say "lost in netsplit" as last quit message instead of "<server> <server>". -- weasel
- This isnt possible because services doesn't know it was due to a split, it just gets a QUIT message with a reason.
- I tell a lie, this may indeed be possible.
- This isnt possible because services doesn't know it was due to a split, it just gets a QUIT message with a reason.
- also print help when commands fail. e.g. "register" should not just say "insufficient parms" -- w
- drop should be a 2 phase process: -w
"DROP" should respond with "if you really blablabla use "DROP <cookie>"
then "DROP <cookie>" should really drop it.
this can be done without state. use an hmac and give it something like "DROP:<date>:<nick>" as its input. send "<date>:<output of hmac>" to the client. For verification just run the HMAC again. the secret key for the hmac is in services config.
UNLINK is not working. -w
Thu 08:09:40 <t2> link t1 t2 Thu 08:09:40 -NickServ(services@newservices.testnet.oftc.net)- Nickname t2 is now linked to master t1. Thu 08:09:41 <t2> info t1 Thu 08:09:42 -NickServ(services@newservices.testnet.oftc.net)- ENFORCE is OFF Thu 08:09:42 <t2> info t2 Thu 08:09:42 -NickServ(services@newservices.testnet.oftc.net)- ENFORCE is OFF Thu 08:09:59 <t2> set enforce on Thu 08:09:59 -NickServ(services@newservices.testnet.oftc.net)- SET ENFORCE to ON. Thu 08:10:00 <t2> info t1 Thu 08:10:01 -NickServ(services@newservices.testnet.oftc.net)- ENFORCE is ON Thu 08:10:01 <t2> info t2 Thu 08:10:02 -NickServ(services@newservices.testnet.oftc.net)- ENFORCE is ON Thu 08:10:11 <t2> unlink Thu 08:10:11 -NickServ(services@newservices.testnet.oftc.net)- Nickname t2 is now unlinked. Thu 08:10:13 <t2> info t1 Thu 08:10:13 -NickServ(services@newservices.testnet.oftc.net)- ENFORCE is ON Thu 08:10:16 <t2> info t2 Thu 08:10:16 -NickServ(services@newservices.testnet.oftc.net)- ENFORCE is ON Thu 08:10:20 <t2> set enforce off Thu 08:10:20 -NickServ(services@newservices.testnet.oftc.net)- SET ENFORCE to OFF. Thu 08:10:21 <t2> info t2 Thu 08:10:21 -NickServ(services@newservices.testnet.oftc.net)- ENFORCE is OFF Thu 08:10:22 <t2> info t1 Thu 08:10:22 -NickServ(services@newservices.testnet.oftc.net)- ENFORCE is OFF
DROP is broken -w
Fri 05:11:35 <t1> drop Fri 05:11:35 -NickServ(services@newservices.testnet.oftc.net)- If you are sure you wish to drop this nickname then type /msg NickServ DROP 1175224295:3110E995F4AA84043471F60E6CBD81EA9AFA949B Fri 05:11:38 <t1> drop 1175224295:3110E995F4AA84043471F60E6CBD81EA9AFA949B Fri 05:11:38 -NickServ(services@newservices.testnet.oftc.net)- DROP failed on Nickname t1.
DROP still acts bad on sudo -w
Fri 05:15:58 <weasel> sudo t1 drop Fri 05:15:58 -NickServ(services@newservices.testnet.oftc.net)- Nickname weasel has been DROPped. [at least it dropped t1, not weasel]
somtimes DROP is weird and doesn't ask for a passphrase. Not sure how exactly to reproduce, but it has to do with linked nicks -w
Thu 08:10:42 <t2> drop t1 Thu 08:10:42 -NickServ(services@newservices.testnet.oftc.net)- Nickname t2 has been DROPped. Thu 08:10:53 <t2> info t1 Thu 08:10:53 -NickServ(services@newservices.testnet.oftc.net)- Nickname t1 is not registered. Thu 08:10:54 <t2> info t2 Thu 08:10:54 -NickServ(services@newservices.testnet.oftc.net)- t2 is currently online. [...] Thu 08:11:00 <t2> drop t2 Thu 08:11:00 -NickServ(services@newservices.testnet.oftc.net)- DROP failed on Nickname t2. Thu 08:11:02 <t2> info t2 Thu 08:11:02 -NickServ(services@newservices.testnet.oftc.net)- t2 is currently online. [..] Thu 08:11:04 <t2> drop Thu 08:11:04 -NickServ(services@newservices.testnet.oftc.net)- DROP failed on Nickname t2.
When not opered then "info" and "info <mynick>" give different levels of info when they probably should be equivalent. Maybe even info <nicklinkedtomine> should give me full info. -w
Fri 05:06:24 <t2> info Fri 05:06:24 -NickServ(services@newservices.testnet.oftc.net)- t2 is currently online. Fri 05:06:24 -NickServ(services@newservices.testnet.oftc.net)- Time registered: Fri 30 Mar 2007 03:05:36 +0000 Fri 05:06:24 -NickServ(services@newservices.testnet.oftc.net)- Last quit message: Unknown Fri 05:06:24 -NickServ(services@newservices.testnet.oftc.net)- Last quit time: Unknown Fri 05:06:24 -NickServ(services@newservices.testnet.oftc.net)- URL: Not set Fri 05:06:24 -NickServ(services@newservices.testnet.oftc.net)- Cloak String: Not set Fri 05:06:24 -NickServ(services@newservices.testnet.oftc.net)- eMail address: t@2 Fri 05:06:24 -NickServ(services@newservices.testnet.oftc.net)- Language set to English(0). Fri 05:06:24 -NickServ(services@newservices.testnet.oftc.net)- ENFORCE is OFF Fri 05:06:24 -NickServ(services@newservices.testnet.oftc.net)- SECURE is OFF Fri 05:06:24 -NickServ(services@newservices.testnet.oftc.net)- PRIVATE is OFF Fri 05:06:24 -NickServ(services@newservices.testnet.oftc.net)- CLOAK is OFF Fri 05:06:26 <t2> info t2 Fri 05:06:26 -NickServ(services@newservices.testnet.oftc.net)- t2 is currently online. Fri 05:06:26 -NickServ(services@newservices.testnet.oftc.net)- Time registered: Fri 30 Mar 2007 03:05:36 +0000 Fri 05:06:26 -NickServ(services@newservices.testnet.oftc.net)- Last quit message: Unknown Fri 05:06:26 -NickServ(services@newservices.testnet.oftc.net)- Last quit time: Unknown Fri 05:06:26 -NickServ(services@newservices.testnet.oftc.net)- URL: Not set Fri 05:06:26 -NickServ(services@newservices.testnet.oftc.net)- Cloak String: Not set Fri 05:06:26 -NickServ(services@newservices.testnet.oftc.net)- eMail address: t@2
- when info'ing a nick, it should show the master nick's information (when linked), or the current nick's info?
- There is no difference. They are the same account, only with a list of nicks attacked to it, one of which is the master nick. -- weasel
- every nick is registered separately, so one should see every nicks registration and usage info (like last login), imho -- cemc
- This is now how nickserv works anymore, you register an 'account' and put 'nicknames' on it, the account is what has the usage info on it, nicknames are just that, nicknames. -- cryogen
- every nick is registered separately, so one should see every nicks registration and usage info (like last login), imho -- cemc
- There is no difference. They are the same account, only with a list of nicks attacked to it, one of which is the master nick. -- weasel
- when info'ing a nick, it should show the master nick's information (when linked), or the current nick's info?
16:26 < cryogen> someone do me a favour and log this on the wiki 16:26 < cryogen> 15:26 <cryogen> access del 1 16:26 < cryogen> 15:26 -NickServ(services@newservices.testnet.oftc.net)- 0 ACCESS entries 16:26 < cryogen> deleted. 16:26 < cryogen> 15:26 <cryogen> access list 16:26 < cryogen> 15:26 -NickServ(services@newservices.testnet.oftc.net)- ACCESS list:2-argument identify confuses services if my nick is already the right one. -w
Fri 17:02:49 <t1> identify t1 Fri 17:02:49 -!- Mode change [+R] for user t1 Fri 17:02:49 -NickServ(services@newservices.testnet.oftc.net)- You are sucessfully identified as t1. Fri 17:02:51 <t1> identify t1 t1 Fri 17:02:51 -!- You're now known as Guest5 Fri 17:02:51 -!- Mode change [-R] for user t1 Fri 17:02:51 -!- You're now known as t1 Fri 17:02:51 -NickServ(services@newservices.testnet.oftc.net)- t1 is a registered nickname and you are not on its access list. If this is Fri 17:02:51 -NickServ(services@newservices.testnet.oftc.net)- your nickname, you may authenticate yourself to services with the IDENTIFY Fri 17:02:51 -NickServ(services@newservices.testnet.oftc.net)- command.
- regain help is broken in nickserv - no usage/syntax info -w
- the convert script does not properly set NULL in many cases it appears. A converted nick for instance has "Last quit message: " and "URL: "
while a newly created one has "URL: Not set" and "Last quit message: Unknown". -w * also, info nick should give opers and the nick owner a list of linked nicks. -w
set master wrong -w
Sun 17:09:25 <t12> set master Sun 17:09:25 -NickServ(services@newservices.testnet.oftc.net)- Wrong number of parameters. Expected at least 1 and no more than 1. Sun 17:09:25 -NickServ(services@newservices.testnet.oftc.net)- Got 0. Sun 17:09:25 -NickServ(services@newservices.testnet.oftc.net)- Usage: SET MASTER [nickname]
- age in date infos would be very useful. E.g. Time registered: Fri 29 Oct 2004 02:23:32 +0000 could say (2 years, 4 months, 3 weeks, 6 days, 14:48:30 ago). -w
"wrong number of parameters" has confusing counts. Not sure how to properly fix this, but it should be changed -w
Sun 17:09:25 <t12> set master Sun 17:09:25 -NickServ(services@newservices.testnet.oftc.net)- Wrong number of parameters. Expected at least 1 and no more than 1. Sun 17:09:25 -NickServ(services@newservices.testnet.oftc.net)- Got 0.
- Access denied message could be better. In addition to saying "You do not have access to the DROP command." it could suggest that I identify first when I'm not +R. -w
- does nickserv need a last-seen in addition to last quit? people can go away with nick changes for instance. -w
- nickserv info output "foo is online as bar" should probably also work if it's not the master that is online - w
ChanServ prints (null) values: -w
Sun 22:41:42 <weasel> info #t2 Sun 22:41:42 -ChanServ(services@newservices.testnet.oftc.net)- channel Information about #t2 Sun 22:41:42 -ChanServ(services@newservices.testnet.oftc.net)- Description: t2 Sun 22:41:42 -ChanServ(services@newservices.testnet.oftc.net)- URL: (null) Sun 22:41:42 -ChanServ(services@newservices.testnet.oftc.net)- eMail: (null) ...
- It would be nice to know if a string setting is just NULL or if it is set to "Not set" in for instance Cloak String. Maybe the NULL value could be printed non-bold? -w
- nickserv sendpass
- complete services language files
- info nick should give opers and the nick owner a list of channels on whose access list they are -w
- use temporary klines instead of klines for akill
- operserv should send snotes when akills expire
- can settings in chanserv info be indented like in nickserv
- operserv should say when masks are already on the akill list
- services do not re-enforce klines. test it akilling a client, UNKLINE it in ircd, and join it again.
- properly send QUIT or PART for all "clients" (like chanserv and friends) who are in any channels when shutting down, so that we do not get ugly netsplits when we try to restart services
- autoop, autovoice channel settings
- it seems we do not re-prepare statements on reconnect
- why do we get a "Foo is not registered" on info, when in reality the prepared statement is gone? Surely there are different error types?
- floodserv
- implemented, in need of testing (please don't complain to me about the metrics, someone else can tune them) -tj
- jupeserv
- also implemented, please test (yes it returns 402 No such server for jupitered servers) [love it or hate it] -tj
- chanserv uses cached info (it still knows about some channels, even when the prepared statements are gone)
- are any safeguards in place so that the queries[] array is properly structured, i.e. the enum values match their queries' index?
Fix the underlying cause for: entry message is cut off in chanserv info:
Mon 15:33:01 -ChanServ(services@newservices.testnet.oftc.net)- Entry Message: welcome to the kernelnewbie
something is sending broken SQL to postgres, and I bet it's services despite all of stu's shrugs. note how the commas are missing once we go to two digit $variables.
May 2 22:23:58 131.123.39.45 postgres[15230]: [4-1] 2007-05-02 22:23:58 UTC ERROR: syntax error at or near "language" at character 178 May 2 22:23:58 131.123.39.45 postgres[15230]: [4-2] 2007-05-02 22:23:58 UTC STATEMENT: UPDATE account SET url=$1, email=$2, cloak=$3, flag_enforce=$4, flag_secure=$5, May 2 22:23:58 131.123.39.45 postgres[15230]: [4-3] flag_verified=$6, flag_cloak_enabled=$7, flag_admin=$8, flag_email_verified=$9, flag_private=$10 language=$11 last_host=$12 May 2 22:23:58 131.123.39.45 postgres[15230]: [4-4] last_realname=$13 last_quit_msg=$14 last_quit_time=$15WHERE id=$16
- MLOCK on burst issues
- fix duplicate mode issue / callback
- fix configure to output #define IPV6
- operserv mod list
- jupeserv reasons
in info <nick> sort the channels to which the user has access to -- weasel