[IRCServices] RE: my recent feature request

[Craig McLure]

aah, my mistake, i dont see any problem with this then :)

/****************************************
  *     Craig "FrostyCoolSlug" McLure
  *       Craig at FrostyCoolSlug.com
  * InspIRCd   - http://www.inspircd.org
  * ChatSpike  - http://www.chatspike.net
  ****************************************/

youph at earthlink.net wrote:
> Craig McLure wrote:
> 
>> heh, i think we are all still recovering from christmas, i've not seen 
>> many posts here over that season.
>>
>> I personally (and i think andy would have the same responce, i've 
>> gotten to know him over the past few years), would shoot down this 
>> idea, it has quite a large potential to be abused, if you write a 
>> patch, ensure only specific IPs can issue the command, otherwise you 
>> will have users just making scripts which periodicly register nicks, 
>> and you'll only become suspicious when your nick.db is 3gigs big :p
>>
>> My approach would be a seperate module, which deals with the command, 
>> whether its an 'extention' to nickserv with a new command, or a 
>> completly new service which manages it (The second is the method we 
>> used for our web interface), that way, you could also publish your 
>> work, and give the others the benifit of your experiance (but ofc, 
>> thats up to you).
>>
>> As for a feature request 'process', just post ideas to the list, they 
>> will be read over, if not responded too.
>>
>> /****************************************
>>  *     Craig "FrostyCoolSlug" McLure
>>  *       Craig at FrostyCoolSlug.com
>>  * InspIRCd   - http://www.inspircd.org
>>  * ChatSpike  - http://www.chatspike.net
>>  ****************************************/
>>
>> youph at earthlink.net wrote:
>>
>>> I'm just wondering if there is any 'official' feature request process 
>>> or if Andrew Church just takes what he likes from this list into 
>>> account when adding new features. I do appreciate Anton Wolkov's 
>>> input, but I was hoping for a response from the developer at least 
>>> either agreeing with or shooting down my idea/request.
>>>
>>> Maybe I should roll up my sleeves and write a patch myself (sigh.)
>>>
>>> --Matt
>>> ------------------------------------------------------------------
>>> To unsubscribe or change your subscription options, visit:
>>> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>>>
>> ------------------------------------------------------------------
>> To unsubscribe or change your subscription options, visit:
>> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>>
> Craig,
> 
> I think you have the wrong idea concerning how I would implement the 
> feature I requested. Let me rephrase my idea/request.
> 
> I would like the ability for Services Admins to be able to set a user 
> password using an MD5 hash, when using MD5 encrypted passwords with 
> services. Normally, a user registers a nick and provides a plaintext 
> password. This plaintext pass is then hashed and stored in the db (if 
> encryption is enabled which I am saying is true in this instance.) I 
> would like the ability for Services Admins to be able to *directly* set 
> this parameter in a nick record. I.E. I would like to be able to change 
> the *hashed* passwords of users. The only command for dealing with MD5 
> passwords is resetting. It would seem trivial to add the ability to 
> simply overwrite the MD5 hash parameter in the nick record. The reason 
> being I am trying to automate a registration process that starts with a 
> web forum registration and will (hopefully) also register a nick name on 
> IRC for the user. I would only have the MD5 hash of the user's password 
> though, which leads me to this request.
> 
> I don't see *any* abuse potential as this command extension would be 
> restricted to Service Admins, I think you just were confused by my 
> description.
> 
> --Matt
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>