View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004104 | unreal | module api | public | 2012-04-09 10:43 | 2012-10-15 15:30 |
| Reporter | syzop | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.2.10-rc1 | ||||
| Fixed in Version | 3.2.10-rc1 | ||||
| Summary | 0004104: modulize client CAP system & add disable options | ||||
| Description | Modulize the new CAP system, so modules can add/remove clicap's... similar to how ISupport, User Modes, and so on are modulized. This means moving part of m_cap.c to the core. Additionally, when at it, add the possibility to disable SASL. Also add the possibility to disable CAP altogether. Since all those happen pre-auth, if a serious (crash)bug has been found it should be possible to quickly disable the feature. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
idea: enable sasl conditionally based on whether or not services requests it in PROTOCTL. thoughts? this would allow clients to skip trying to do SASL auth on networks which don't support it (such as anope networks). |
|
|
Yes, good point. Because right now with SASL, the client just waits for XX seconds and times out? |
|
|
actually, this wouldn't work because we don't share global capability data. i guess it would need to be a setting. :) obviously the real fix here is for anope to implement SASL support, but they probably won't do that for a while. |
|
|
Well, SASL is an option, it's not mandatory for services to implement. And, of course, there are also servers (and networks) without services. In any case, this new feature shouldn't cause a delay for networks that don't use SASL-capable services. Perhaps we should just default it to off, and have the admin enable it explicitly. Auto-discovery is also an option, but I really get the feeling that we are making things overcomplicated then. (If a network does use SASL-capable services and they are temporarily down and you get a delay then.. so be it.. but if you never have SASL-capable services connected, the delay is just a waste) |
|
|
perhaps a fix with sasl is to specify a sasl_server option. this could avoid auto-discovery of sasl agents. |
|
|
What I have in mind is something like set::enable-sasl yes/no or set::options::sasl. What is also possible is set::sasl-server <servername>. Only if this is specified enable SASL. And no longer use SERVICES_SERVER for this. Is that last option what you meant? Or something else? |
|
|
http://hg.unrealircd.com/hg/unreal/rev/8db85bd24b93- SASL now needs to be enabled explicitly by setting a set::sasl-server. If this is not set, then SASL is off and not advertised. If the specified server is not connected, then SASL is off as well. This prevents unnecessary delay (and the inability for some clients to get online) when SASL is not in use or when the SASL server is down. I realized it would be good to not advertise SASL when the sasl server is down, so that required adding some hacks (which are necessary whether CAP gets modulized or not). Clients such as KVIrc are unable to get online if SASL is advertised and the SASL server does not respond. The original target for this bug, the modulization of CAP, still needs to be done. |
|
|
set::sasl-server is a good approach, indeed. i'm going to add this to charybdis as a hint for advertising the sasl capability i think :) |
|
|
the disable feature is assigned to me, mandatory for 3.2.10. the modularization is not a release target, and not assigned to me. |
|
|
http://hg.unrealircd.com/hg/unreal/rev/2680c44b18fe - Added set::options::disable-cap, which can be used to disable the new CAP support (0004104). The ability to use, or not use, SASL was already implemented. This means only the modularization of CAP is left, which is now tracked in 0004131. This issue can be closed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-04-09 10:43 | syzop | New Issue | |
| 2012-04-09 10:43 | syzop | Relationship added | child of 0003915 |
| 2012-04-12 02:39 |
|
Note Added: 0016979 | |
| 2012-04-12 21:17 | syzop | Note Added: 0016980 | |
| 2012-04-18 13:48 |
|
Note Added: 0016983 | |
| 2012-04-29 11:17 | syzop | Note Added: 0016985 | |
| 2012-04-29 11:18 | syzop | Note Edited: 0016985 | |
| 2012-05-04 18:11 |
|
Note Added: 0016987 | |
| 2012-05-05 10:45 | syzop | Note Added: 0016988 | |
| 2012-05-07 16:27 | syzop | Assigned To | => syzop |
| 2012-05-07 16:27 | syzop | Status | new => assigned |
| 2012-05-07 16:52 | syzop | Note Added: 0016993 | |
| 2012-05-07 16:52 | syzop | Assigned To | syzop => |
| 2012-05-07 16:52 | syzop | Status | assigned => acknowledged |
| 2012-05-11 12:07 |
|
Note Added: 0017001 | |
| 2012-10-06 12:31 | syzop | Note Added: 0017152 | |
| 2012-10-06 12:31 | syzop | Assigned To | => syzop |
| 2012-10-06 12:31 | syzop | Status | acknowledged => assigned |
| 2012-10-15 15:27 | syzop | Issue cloned: 0004131 | |
| 2012-10-15 15:28 | syzop | Note Added: 0017175 | |
| 2012-10-15 15:28 | syzop | Status | assigned => resolved |
| 2012-10-15 15:28 | syzop | Fixed in Version | => 3.2.10-rc1 |
| 2012-10-15 15:28 | syzop | Resolution | open => fixed |
| 2012-10-15 15:28 | syzop | Note Edited: 0017175 | |
| 2012-10-15 15:30 | syzop | Relationship added | related to 0004131 |
| 2017-01-06 15:48 | syzop | Category | module => module api |
