Print

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

[jhaye]

I would like to see a module that would function some what like Hostserv's //hs request

With a command to reject all registration requests, approve all, and a singular approve/reject.

For instance, someone is flooding your server with bots and registering their names, I would like the registration process to be slightly different. Instead of automatically being registered, the nickname would have to be approved via command, before the nickname is actually considered registered.

This would be a life saver to prevent me and possibly other people from having to dig through the nickserv list command to manually drop nicks that were registered.

I'm aware of the option available that allows a passcode or verification to be sent to their email addresses, but I'm not to fond of it.

If anyone would be able to implement this feature that would be amazing.

TLDR version;
I would like to see a module that would function some what like Hostserv's //hs request

With a command to reject all registration requests, approve all, and a singular approve/reject.
Nickname isn't considered registered until its approved

[katsklaw]

This scenario is the exact reason email auth exists. I understand you may not be fond of it. However, that is it's purpose. In the original spirit of NickServ, it is so users can register freely without having to rely on IRCop intervention to reserve their nick. This is why the current process is in place.

Reference registration throttling, It's already in place since sometime in 1.7.x

Code: [Select]

# NickRegDelay <seconds> [OPTIONAL]
#     Prevents users from regging their nick if they are not
#     connected for at least X seconds.
#NickRegDelay 30
There is also another delay between registrations.

You can also delay the /ns RESEND command:

Code: [Select]

# NSResendDelay <time>  [RECOMMENDED]
#     Sets the minimum length of time between consecutive uses of the
#     RESEND command.  If not given, this restriction is disabled (note
#     that this allows "resend flooding" or "mail bombing").

NSResendDelay  90s

Combined with limiting users to a certain number of nicks per email via (This only works if you require an email address to register):

Code: [Select]

# NSEmailMax [OPTIONAL]
# Module: ns_maxemail
#
# Limit the amount of registrations with the same email address to the
# amount given here. If set to 0 or left commented, there will be no limit
# enforced when registering new accounts or using /msg NickServ SET EMAIL.
#
#NSEmailMax 1
Now for those that have already registered on your network you can do a mass drop by referencing the email address used, that is unless you disabled the email address requirement, in which case you basically opened registration up full tilt. The mass drop at: http://modules.anope.org/index.php?page=view&id=87

Additionaly you can make registration a 2 step process without using emailreg with a module found at: http://modules.anope.org/index.php?page=view&id=78

Now in reference to your request, it is certainly possible and I don't think one like it exists. I personally stick to nets that allow open registration, which is why I don't hang out on UnderNet and the like. Most users that come from NickServ style nets will agree and while I'm not telling you how to run your network, this is something you should consider very very carefully. The modules and features I've discussed here will cure your problem for sure without needing an IRCop to register your nick for you.

Please understand that in the end, it's your users that need to be happy with your network and thus their needs come before yours. If you want to require IRCop intervention and they do not, then you lose. If the burden of dropping spammer nicks increases, hire more staff but keep your loyal users happy or some other network will.

Hope that helps.

[jhaye]

This scenario is the exact reason email auth exists. I understand you may not be fond of it. However, that is it's purpose.

The quote below is why we do not require email verification.

it's your users that need to be happy with your network and thus their needs come before yours.

The users would much rather require an IRCOp to approve their registration than to have their channel join flooded with hundreds of bots.

Additionaly you can make registration a 2 step process without using emailreg with a module found at: http://modules.anope.org/index.php?page=view&id=78

The above is easily worked around using a scripted reply to the notice event.

Now for those that have already registered on your network you can do a mass drop by referencing the email address used, that is unless you disabled the email address requirement, in which case you basically opened registration up full tilt. The mass drop at: http://modules.anope.org/index.php?page=view&id=87

The above module would help with dropping mass amounts of names, provided that they aren't randomly generated nicks names. Mind you I do use the anti-random module.

Code: [Select]


# NickRegDelay <seconds> [OPTIONAL]
#     Prevents users from regging their nick if they are not
#     connected for at least X seconds.
#NickRegDelay 30
^ Could help somewhat, unless no one is around and they connect hundreds of bots and wait the time required to register and then register.

Code: [Select]

# NSEmailMax [OPTIONAL]
# Module: ns_maxemail
#
# Limit the amount of registrations with the same email address to the
# amount given here. If set to 0 or left commented, there will be no limit
# enforced when registering new accounts or using /msg NickServ SET EMAIL.
#
#NSEmailMax 1

^ Would only work if they used the same email for each registration, which rarely happens.
Don't get me wrong, I appreciate your input and I hope to receive more. However, I really believe the idea is a good one and would be useful for others as well as myself.

I honestly can't think of a loophole using the suggested module.

[Jobe]

In all honesty though I do like the idea of admin/oper approval of nick registrations as it can have uses outside of spam registration prevention.

Even most good forum packages provide a choice between none, email, admin and email+admin activation for registrations.

[nuk3d]

There are services, like Quakenet's "Q", that sends an email with a link that goes to a Recaptcha image.

Additionaly you can make registration a 2 step process without using emailreg with a module found at: http://modules.anope.org/index.php?page=view&id=78

I was thinking could you use that module as an example, but make it use a Recaptcha image instead of a code you get on the irc. Would that even be possible though?

[Charles Kingsley]

http://modules.anope.org/index.php?page=view&id=164

[jhaye]

http://modules.anope.org/index.php?page=view&id=164

I would just like to keep bot registration spam to a minimum without placing too much to do on the users part to register. I don't know about you guys but I sincerely hate captchas.
I think that module would be to much hassle for a user to have to do to register.

[Jan Milants]

As a user I 'd much rather have to activate through a captcha or an email myself then have to wait for one of those lazy opers to come online.. 

[katsklaw]

Jobe, point taken.

Jhaye, you continually refer to "massive amounts of bots", do you not run any kind of dnsbl scanner either?! Perhaps this is why you have such a problem in the first place *shrug*. In my 14 years I can honestly say I've never had any such problem.

By not using NSEmalReg you really are making it easier for bots, not harder. So sorry, but common sense tells me to use the most restrictive solution available, even if you don't like it until such a time as what you really want is available. There are other modules I didn't even mention that could help too on the modules site.

I suppose as a quick fix until someone writes such a module you can unload ns_register and have your users go to your oper channel and ask someone to saregister the nicks for you. http://modules.anope.org/index.php?page=browse&name=saregister&cat=1&anopever=-1&sort=name&ord=asc

I have some free time this coming weekend, perhaps I can put something crude together. However I only do 1.8x modules.

[jhaye]

The dnsbl does not catch every single proxy their is, it only partially works.  I know you can have BOPM scan the users ip address, or have it check the blacklists. If BOPM doesn't find it in the list, no action is taken and if the user passes the scan no action is taken. Correct me if I am wrong here, but if i remember correctly you can add ports to have BOPM scan to the configuration file.

Adding most common used ports can be good, as long as its not the ports people use for a webserver or an ircd. But there is no real way to stop them fully with BOPM an ip change in most cases would suffice to beat BOPM.

Long story short, BOPM or the dnsbl isn't 100% dependable, they'll only work using preconfigured lists / port scans.

I'm not saying I don't use any of the aforementioned methods, I am just trying to support my idea.

[MeiR]

jhaye, I don't see any problem to implement your needs without a module.

When email registration is enabled, opers can manually approve a nick, with "/ns confirm nick", instead of the user to enter his mail.
In addition, these opers can see all uncofirmed nicks with "/ns list * unconfirmed".

I remind you that an unconfirmed nick isn't considered as registered, and after 1 day (or whatever you set it "NSRExpire" directive), unconfirmed nicks will cancel.
So attckers' nicks won't be added to nickserv database at all, only temporary to the "PreNickServDB".

And if you ask me what about users who will register during that day and their request can expire too, I'll answer that also the mass rejecting won't help in this case, since your opers will have to filter the list anyway, in order to know who to confirm first, before they mass reject.


What I can suggest to Anope team, is that the unconfirmed list output will be numbered, and the "/ns confirm" command will have the option to use a range as an argument (e.g. "/ns confirm 1-13"), just like many other multiple commands in services.

[katsklaw]

Meir, he doesn't want email registration.

[jhaye]

Meir, he doesn't want email registration.

Yeah, our users complained until we finally decided not to use that anymore. So I am trying to avoid that at all costs.

[katsklaw]

jhayre, something else you can do while you wait for a module is have any channel founder that is afraid they will be bombarded by bots is they can set and/or modelock chanmode +R. This requires a nick to be registered and identified before they can join the channel.

While yes, it's possible for a spam bot to register their nick. I've never heard of any that do.

[jhaye]

jhayre, something else you can do while you wait for a module is have any channel founder that is afraid they will be bombarded by bots is they can set and/or modelock chanmode +R. This requires a nick to be registered and identified before they can join the channel.

While yes, it's possible for a spam bot to register their nick. I've never heard of any that do.

This is the main reason I requested a module to allow opers to approve the nick and it remain unregistered until this is done, because the people that flood my network are script kiddies with nothing better to do than flood.  The ones we are dealing with currently are all registering, then join flooding. I use the +j mode, +f and encourage others to use it.

They do more than just join floods, but that is really the only issue thats tougher to stop due to them registering their nicks. It really forces you to lock the channel down with +i and +m

[Jan Milants]

Piss easy to implement in a module using the existing framework in 1.8 of requested nicknames.. just requires a bit of copy pasting, some restructuring and some cleaning up... something similar can probably be done in 1.9..

Though I still don't see much use for it.. personally, as a user, I d much rather have control over the entire process myself..

But anyhow.. I probably just wasted 90 minutes of my life..
Disclaimer: I wrote the thing, I didn't actually test it... still an issue on the TODO as well..

[jhaye]

Piss easy to implement in a module using the existing framework in 1.8 of requested nicknames.. just requires a bit of copy pasting, some restructuring and some cleaning up... something similar can probably be done in 1.9..

Though I still don't see much use for it.. personally, as a user, I d much rather have control over the entire process myself..

But anyhow.. I probably just wasted 90 minutes of my life..
Disclaimer: I wrote the thing, I didn't actually test it... still an issue on the TODO as well..

I really appreciate your effort to help me. This should make our lives easier. Would you like me to post anything I may find wrong with the module? (not that there would be)

[katsklaw]

Jan, thanks for doing that. I just found that I won't have as much free time this weekend as I thought. cheers! Although I was going to do basically the same copy and paste. lol

UPDATE: Jan, wonderful work as usual. Few things though. Might want to think about memoing opers and requesters like hs_request does. Instead of sending to host setters, perhaps a config directive to sent staff or send to a channel. You also have a typo: grep -i "straff"

[jhaye]

Yes, notifying opers that a request was made would be great. There is another issue that I have noticed.
Once a user is confirmed, they can not identify without changing to a different nick name then back to their newly confirmed one.

I will update this post with anything else I find.

There's one more problem I can see for now. There is no command to deny a request. I'm assuming that you set it up this way to let the request just expire ?

[Jan Milants]

Feel free to post bugs.. I haven't published the module yet, wanted to fix the conflict with nsemailreq first...

Will look at the notification of the services chan.. can probably copy paste this from hs_request_ext..

And yeah.. I fail to see the use of a reject command because requests will generally expire within 24 hours.. since the module uses the standard anope nick request infrastructure a reject command could easily be coded in a separate module, but I won't be doing that part 

[Jan Milants]

I think I've mostly finished it and it s working properly... the memo'ing is still an issue though because anopes send functions only allow emails to come from a recognized valid user.. which obviously isn't the case yet for a user trying to request a nick.. 

[Jan Milants]

I think I have managed to work around that issue by replacing core functionality.. not sure whether other 3rd party modules working on memoserv will like it, but it should work on a normal anope install and with non memoserv related modules without any probs...

If someone cares to test before I publish it pls.. 
http://vips.hopto.org/gitweb/?p=anope-modules/ns_request;a=summary