Anope IRC Services

Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1]   Go Down

Author Topic: Module idea  (Read 6281 times)

0 Members and 1 Guest are viewing this topic.

mooncup

  • Contributor
  • *
  • Offline Offline
  • Posts: 65
Module idea
« on: May 22, 2009, 10:29:02 AM »

botserv request.

Basically /bs request nick username host.name real name.

Then opers can /bs activate or /bs reject in the same way as hostserv.

This is to save channel owners joining network channels to ask / pming an oper.
Logged

Charles Kingsley

  • Contributor
  • *
  • Offline Offline
  • Posts: 1405
Re: Module idea
« Reply #1 on: May 22, 2009, 10:53:34 AM »

Yep, good idea.
Logged

Charles Kingsley

  • Contributor
  • *
  • Offline Offline
  • Posts: 1405
Re: Module idea
« Reply #2 on: May 22, 2009, 11:00:09 AM »

Expand to limit abuse:

Request has to be for a channel owned by the requestor to reduce abuse.
Request can only be x times per y time duration, 1 request per day/week, etc.

Still think it's a good idea given you can request a vhost, why not a bot?
Logged

MeiR

  • Anope User
  • Offline Offline
  • Posts: 49
Re: Module idea
« Reply #3 on: May 22, 2009, 04:21:48 PM »

I think it'll be nice if limitations are set with conf directives.
another limits i thought about:
- min number of days the chan is registered.
- number of users in channel during requesting
(- auto rejection, after some checking of badwords in argumetns prvided?)
the first two will encourage channels registration and activity, all of crouse according to network owners desire
Logged

mooncup

  • Contributor
  • *
  • Offline Offline
  • Posts: 65
Re: Module idea
« Reply #4 on: May 22, 2009, 04:57:18 PM »

I think it'll be nice if limitations are set with conf directives.
another limits i thought about:
- min number of days the chan is registered.
- number of users in channel during requesting
(- auto rejection, after some checking of badwords in argumetns prvided?)
the first two will encourage channels registration and activity, all of crouse according to network owners desire

I like the conf idea, and the first 2 ideas, but I'm not sure about coding autorejection in directly. I was thinking it would work basically exactly like hostserv, so people can implement clientside autorejection like is currently done with hostserv.
Logged

MeiR

  • Anope User
  • Offline Offline
  • Posts: 49
Re: Module idea
« Reply #5 on: May 22, 2009, 05:06:53 PM »

yea u'r right.
it'll also add for you unwanted extra time of implemeting.
there can always be improvements in later versions :)
Logged

Craig

  • Anope User
  • Offline Offline
  • Posts: 2
Re: Module idea
« Reply #6 on: June 15, 2009, 08:01:59 PM »

HERE IS BS_REQUEST

/* -----------------------------------------------------------------------
 * bs_request.c - a module to facilitate user requests for botserv bots
 * and simple bot list management tools.
 *
 * Ver 2.14.
 *
 * 4/19/2006,   changed security check for "BOT" .. was done insecurely
 *
 * 4/12/2006,    added normal support for ANOPE1.6.x and older 1.7.x
 *      cleaned up lefover code from testing...
 *
 * 4/11/2006,    small bug with unassign fixed.
 *
 * 
 * The commands were modeled around hs_request for familiarity, eg.     
 * waiting, request, activate, etc.                                                   
 *                                                                       
 * This module was private to criten irc network, but we have decided to 
 * release it to public domain due to repeated requests for the code.     
 * This software is made available under GNU GPL license.                     
 * No warrantees or guarrantees whatsoever are made, but we will do our   
 * best to provide support.                             
 *                                                                       
 * by: drak <drak@criten.net> irc.criten.net #development
 * minor fixes by CyberWarrior.
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details at:
 *
 * http://www.gnu.org/licenses/gpl.txt
 *
 * ------------------------------------------------------------------------
 *
 * Functions Provided:
 *
 *   REQUEST, request a bot.       Access: registered user
 *   SHOW, shows your requests.       Access: registered user
 *   CANCEL, cancel a request.       Access: requestor only
 *   WAITING, list waiting requests.     Access: hostsetter/sa
 *   ACTIVATE, approves a request.       Access: hostsetter/sa
 *   REJECT, rejects a request.       Access: hostsetter/sa
 *   STATS, shows count of bots/unused    Access: SA
 *   UNUSED, lists unassigned bots.       Access: SA
 *   PURGE, wipes ALL unassigned bots.    Access: SRA
 *
 * Hooks installed:
 *
 *   BOT ADD - check to make sure there is no conflicting request waiting.
 *
 * ------------------------------------------------------------------------
 *
 * About:
 *
 * bs_request will allow users to request custom botserv bots.  The request
 * includes these parameters: #channel 0|1 nick ident v.host real name.
 *
 * The channel name is used for tracking and limiting requests, and when
 * the bot is approved, it will be auto-assigned to this channel. The flag
 * parameter (0 or 1) denotes if the bot will be public or private.  If 1 is
 * set here, then after the bot is created, only operators will be able to
 * assign it to further channels.  The nick is checked to make sure its
 * not a user's registered nick and that noone is online with the nick at
 * the time of request, to prevent abuse. The nick and channel are both
 * checked for forbidden status, etc. and the channel must be registered, the
 * requestor must be the channel founder, and the channel must be occupied,
 * both at the time of the request and the time of activation.  The blacklist
 * is a simple exact string match. If any of the blacklisted strings exist
 * anywhere in the reqeust, it will be rejected.  This module also hooks
 * "BOT ADD" to check if they are adding a bot that is already requested,
 * because this will leave "dead" requests in the queue which will cause
 * problems later. Bot requests are managed by channel they are requested
 * for. So to reject one you would /bs reject #channel
 *
 * For more information on the operation of this module, see /bs help.
 *
 * ------------------------------------------------------------------------
 *
 * Acknowledgements:
 *
 * A few bits of code were copied from anope botserv.c
 * Other code/information may be based on works of others.
 *
 * ------------------------------------------------------------------------
 *
 * Configuration:
 *
 * BSCHAN is where botserv should join/announce actions. Remove this if
 *      you dont want it to join a channel.
 * MAXNICK is the max nick length.
 * MAXUSER is the max username length.
 * MAXHOST is the max hostname length.
 * MAXGECOS is the max len of "real name" info field.
 * USE_BLACKLIST define this to enable the text blacklist check.  The
 *      text defined in BLACKLIST is space dilimited, therefore
 *      it needs a space at the end of your string.  Follow
 *      example from the strings listed.
 * ANOPE16 define this for Anope 1.6.x version.
 * ANOPE17old define this if you have issues with this module and older
 *       development versions of anope 1.7.x not being able to locate
 *      functions makebot() and/or unassign().
 *
 **************************************************************************
 * !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 **************************************************************************
 *
 * IF YOU DO NOT DEFINE THE MAX LIMITS ABOVE TO EQUAL OR LESS THAN YOUR
 * NETWORK LIMIT SETTINGS, AND SOMEONE REQUESTS A BOT WHICH EXCEEDS THE
 * LIMITS AND SUBSEQUENTLY GETS ACTIVATED, THE RESULTS *WILL* SUCK.
 * IT WILL MOST ASSURABLY CORE SERVICES.
 *
 * ------------------------------------------------------------------------
 */



BS_REQUEST
*nix:
http://www.criten.net/files/bs_request.c

Windows:
http://www.criten.net/files/bs_request.zip
Logged

Keith

  • Anope User
  • Offline Offline
  • Posts: 4
Re: Module idea
« Reply #7 on: July 23, 2009, 10:04:07 AM »

Doesn't respond to me, I'm using Inspircd 1.2 with the anope 1.8 SVN with Viper Inspircd12 protocol so I guess thats a given lol.
Logged

Jan Milants

  • Team
  • *
  • Offline Offline
  • Gender: Male
  • Posts: 1372
Re: Module idea
« Reply #8 on: July 23, 2009, 11:44:24 AM »

there is no reason why a module like this should be IRCd dependant.. it only changes anopes behaviour.. as long as it uses anope API it shouldn't care about which IRCd is being used..
In this case however the author chose the define all commands that have to be send to the IRCd as raw strings and send them as such to the ircd.. so the module will only be able to work with the ircd it was designed for.

From the looks of it, this was made for 1.6 when anope didn't have an extended API for the ircds yet as it does now.. so it could use a major rewrite.. :)
and that doesn't mean it can't work fine for the ircd it was meant for..
Logged
If you like me donate coins to 1FBmZVT4J8WAUMHKqpWhgNVj3XXnRN1cCk :)
Pages: [1]   Go Up