Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[falerin]

My network has recently switched over to email confirmation for user registration. Unfortunately our PTR records for the mail server are totally beyond our control and for some reason some DNSes seem to not be aware of our reverse dns at all. Since some ISPs are making the illadvised decision to reject silently outright mail from ip's that it cannot reverse resolve we have users that need to have staff confirm their Email manually. However we would like to extend this responsibility to all operators not just those who are Services Operators or Admins. Can Nickserv's confirm command when applied to other users be made available to all operators modularly?

[Jobe]

I have to say as this isnt a feature that is likly to make it in to a core feature a module is probably the best idea.

[falerin]

Which is precisely why it is here in modules as a request.

[n00bie]

Originally posted by falerin
...Can Nickserv's confirm command when applied to other users be made available to all operators modularly?

yes it can be done!

[falerin]

Good. I was not sure as any similiar modules I have to base it off of tend to be producing greater restrictions (i.e. restricting access to only services root rather then less). Our coding staff have several times considered writing a module that extends operserv's oper and admin functionality to allow custom userlevels on a per user and per command basis using a configuration file. Though we had largely looked at this from the perspective of granting them admin status and then removing priviledges rather then starting them at base user and adding priviledges.  This lets me know that the alternative is feasible.  I have not mucked arround with anything at that level on the services end however so that project (likely a very very involved one with countless issues not yet considered) is a long way off. A module that reclassifies nickserv confirm would be a step in that direction and is a more immediately pressing need for the network so that will be the way we proceed.  If any of you who are more facile with this level of anope coding has any advice on how to best proceed such would be greatly appreciate. Of course if you feel really motivated > I would not be adverse to having it coded for me either .

[Jan Milants]

well the way this would be implmented by the module is not as nice as how further restricting a command is.... the module would simply implement the command again and contain all the logic required to execute it, only difference is it would require a lower access level..

[falerin]

Ah so it is indeed that the API allows you to add additional restrictions but not easily take them away without recoding existing functions |:(. That is unfortunately unpleasant. I will have to carefully consider my comfort level with duplicating core functions of nickserv with my own version before I even begin to attempt this especially as confirm deals with both the pre database and the main database. The last thing I want to do is corrupt my database and lose it all....

[Jobe]

I would have thougt, although i don't know if it is the case that the API would allow you to clone the command but have it bypass the access restriction so as to just take it straight to the code that sets the hosts so you could then use that to impose your own modularized access restrictions.

[Jan Milants]

the command and its logic are in a (core) module themselves, and as far as i know can not be accessed from outside that module.

it s not as bad as it sounds though, all you need to do is take the core module and change the access  requirements, then use it to replace the other one...

[falerin]

Well I have in fact attempted to code this module. The module compiles loads and appears to be functioning to a degree up until an operator attempts a forced confirm. At which point the module tells them that the new nick is registered but services crash silently. There is no logged error nor any message sent by services before dying. I suspect however it is a segfault based on behavior.

I do not know about posting code here and its somewhat lengthy anyway so I have used nopaste:

http://rafb.net/paste/results/xNRhaB95.html

Any help would be most greatfully appreciated.

[Dave Robson]

Your using strtok, dont (yes i know the core module uses it).

You then sprintf into passcode without any thought of how long that string will be or how much memory is allocated - again, dont use sprintf, use snprintf and specify the max size.

You then use strtok again - dont, you will break anope's core.

You never free anything at all, so you are leaking memory.

P.S That is just at first glance at the code, i could be wrong/missing thigns

[falerin]

Well what that does say is that it is not as some suggested a simple duplication and modification of the Core Module. I am familiar with tokenizing with strtok. I am unfamiliar with the alternatives (even though I do know that they are prefered and of the reasons that a destructive function like strtok is not). I am also aware that I did not free any allocated memory. I was more concerned with getting the functionality actually working. I would generally go back and optimize afterward. The sprintf is undoubtedly the killer though and I am suprised I did not catch it myself. This is a segfault waiting to happen. What that leaves me with is essentially rewriting the core functionality in a more error resistant way. I am definitely uncomfortable with that. Presumably you and the other Anope Devs, had reasons for selecting the functionality that you did. I may continue trying to write this as I really need the ability for my ops to manually confirm but I may actually want to do this differently.

Would it work to add a command called oconfirm that when an operator sent a confirm request on the nick it called the original confirm as if the original nick had called it with the correct key?

Such an alternative would undoubtedly be more memory efficient then actual duplication of all of the core code...

Thoughts? Ideas?

[Edited on 13-12-2006 by falerin]