View Issue Details

IDProjectCategoryView StatusLast Update
0003276unrealircdpublic2015-11-23 03:11
ReporterStealth Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status acknowledgedResolutionopen 
Platform*OS*OS Version*
Product Version3.2.9-RC1 
Summary0003276: Max bantime
DescriptionIt would be nice to have something like set::max-bantime to restrict K/G/Z:Lines from being too long. It should be up to the individual servers to enforce, so there are no issues with the server2server TKLs, as well as allowing U:Lines to override the restriction.
TagsNo tags attached.
Attached Files
max_bantime.patch (3,282 bytes)
3rd party modules

Activities

WolfSage

2007-05-01 19:51

reporter   ~0013971

This should handle what you're looking for fine. There's the slight issue of it over-riding default-bantime if default-bantime > max_bantime. It makes sense, but a warning or an error should probably be thrown to the user.

Testing and suggestions would be appreciated.

syzop

2007-05-08 13:41

administrator   ~0014051

looks ok? :) (viewed patch only)

syzop

2007-05-08 13:44

administrator   ~0014052

But yeah, a warning would be nice I think... hmmm good pro/con's for both actually (annoying & "yes I know by now" vs "wtf I said perm"), etc... but if we risk any confusion (which we do) always go with the warning IMHO... ;)
(though it should probably be more of a NOTE: rather than WARNING:)

Stealth

2007-05-13 12:03

reporter   ~0014117

Spamfilter can override this, perhaps it should check when the spamfilter is set

If default-bantime > max-bantime, it chould conf fail

A notice to the oper setting the ban would be nice, and let the oper know it has been set as max-bantime

I was unable to test U:Lines, but everything else looks fine

Stealth

2007-05-14 00:17

reporter   ~0014132

Another small note: Perhaps we should also apply this to shuns, since that is a type of ban

stskeeps

2007-05-14 04:41

reporter   ~0014133

Suitable for merging i guess?

WolfSage

2007-05-14 08:15

reporter   ~0014135

Hmm, good points. This should apply to spamfilter as well. I'll add this and default ban checking to spamfilters, and a warning if the values are different, (I don't really think it's worth failing over), and then it should be good to go.

Bricker

2007-05-14 09:43

reporter   ~0014136

i thought unreal was planning of getting rid of shun? it should, its abusive

stskeeps

2007-05-20 03:55

reporter   ~0014189

shun is a fine and good tool.

Shining Phoenix

2007-05-20 04:03

reporter   ~0014192

Using shun on an annoying person is very satisfying. That should be enough reason to keep it =P

Stealth

2009-07-24 00:50

reporter   ~0015895

Updated for possible addition to 3.2.9. Patch is attached, but needs a little more work. (see above)

CoreDuo

2015-11-23 01:03

reporter   ~0018879

Last edited: 2015-11-23 03:11

Would it be possible to retool this request to apply to oper classes in UnrealIRCd 4.x? Feels like it would be considerably more useful there to, for example, limit certain oper classes to certain ban lengths.

Issue History

Date Modified Username Field Change
2007-04-17 19:03 Stealth New Issue
2007-04-18 04:49 stskeeps Status new => acknowledged
2007-05-01 19:49 WolfSage File Added: max_bantime.patch
2007-05-01 19:51 WolfSage Note Added: 0013971
2007-05-08 13:41 syzop Note Added: 0014051
2007-05-08 13:44 syzop Note Added: 0014052
2007-05-13 12:03 Stealth Note Added: 0014117
2007-05-14 00:17 Stealth Note Added: 0014132
2007-05-14 04:41 stskeeps Note Added: 0014133
2007-05-14 04:41 stskeeps Status acknowledged => confirmed
2007-05-14 08:15 WolfSage Note Added: 0014135
2007-05-14 09:43 Bricker Note Added: 0014136
2007-05-19 22:07 WolfSage Status confirmed => assigned
2007-05-19 22:07 WolfSage Assigned To => WolfSage
2007-05-20 03:55 stskeeps Note Added: 0014189
2007-05-20 04:03 Shining Phoenix Note Added: 0014192
2009-07-24 00:50 Stealth QA => Not touched yet by developer
2009-07-24 00:50 Stealth U4: Need for upstream patch => No need for upstream InspIRCd patch
2009-07-24 00:50 Stealth U4: Upstream notification of bug => Not decided
2009-07-24 00:50 Stealth U4: Contributor working on this => None
2009-07-24 00:50 Stealth Note Added: 0015895
2009-07-24 00:50 Stealth Assigned To WolfSage =>
2009-07-24 00:50 Stealth Status assigned => acknowledged
2009-07-24 00:50 Stealth Product Version 3.3-alpha0 => 3.2.9-RC1
2015-08-08 17:52 syzop Severity minor => feature
2015-11-23 01:03 CoreDuo Note Added: 0018879
2015-11-23 01:04 CoreDuo Note Edited: 0018879
2015-11-23 01:05 CoreDuo Note Edited: 0018879
2015-11-23 01:05 CoreDuo Note Edited: 0018879
2015-11-23 01:06 CoreDuo Note Edited: 0018879
2015-11-23 01:07 CoreDuo Note Edited: 0018879
2015-11-23 01:08 CoreDuo Note Edited: 0018879
2015-11-23 03:11 CoreDuo Note Edited: 0018879