View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004131 | unreal | module api | public | 2012-10-15 15:27 | 2013-05-20 19:33 |
| Reporter | syzop | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.2.10-rc1 | ||||
| Fixed in Version | 3.4-alpha1 | ||||
| Summary | 0004131: modulize client CAP system | ||||
| 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. ** OLD STUFF, ALREADY DONE IN 0004104: ** 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. |
|
|
This issue now tracks the modularization of CAP, which would be nice to have one day, but isn't urgent. |
|
|
Modular CAP framework added: http://hg.unrealircd.org/hg/unreal/rev/2d6ad56b647c SASL CAP ownership moved to m_sasl: http://hg.unrealircd.org/hg/unreal/rev/944c173bcfbf TLS CAP ownership moved to m_starttls: http://hg.unrealircd.org/hg/unreal/rev/15cf781c588b |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-10-15 15:27 | syzop | New Issue | |
| 2012-10-15 15:27 | syzop | Status | new => assigned |
| 2012-10-15 15:27 | syzop | Assigned To | => syzop |
| 2012-10-15 15:27 | syzop | Issue generated from: 0004104 | |
| 2012-10-15 15:29 | syzop | Note Added: 0017176 | |
| 2012-10-15 15:29 | syzop | Status | assigned => acknowledged |
| 2012-10-15 15:29 | syzop | Summary | modulize client CAP system & add disable options => modulize client CAP system |
| 2012-10-15 15:29 | syzop | Description Updated | |
| 2012-10-15 15:30 | syzop | Relationship added | related to 0004104 |
| 2012-10-15 15:30 | syzop | Description Updated | |
| 2012-10-16 11:08 | syzop | Assigned To | syzop => |
| 2013-05-20 19:33 |
|
Note Added: 0017641 | |
| 2013-05-20 19:33 |
|
Status | acknowledged => resolved |
| 2013-05-20 19:33 |
|
Fixed in Version | => 3.4-alpha1 |
| 2013-05-20 19:33 |
|
Resolution | open => fixed |
| 2013-05-20 19:33 |
|
Assigned To | => nenolod |
| 2013-05-20 19:33 |
|
Relationship added | child of 0004188 |
| 2017-01-06 15:48 | syzop | Category | module => module api |
