View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000730 | LDMud 3.6 | General | public | 2010-02-25 14:42 | 2022-10-06 18:16 |
| Reporter | zesstra | Assigned To | Gnomi | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.6.3 | ||||
| Summary | 0000730: static logon() function does not work for TLS logon callback | ||||
| Description | For a standard connect logon() in the login object can be static. If tls_init_connection() is called in connect() in the master, the call to logon() in the login object is delayed until TLS handshake finished and the logon() is called. In this case, logon() must not be static. This inconsistency is a bit annoying, especially because it is not documented. However, because arbitrary callbacks can be defined with tls_init_connection(), we can't simply ignore any access modifiers when executing the callback. | ||||
| Tags | No tags attached. | ||||
|
|
The problem should be solved by setting current_object prior to calling the callback. It should be set to the object that called tls_init_connection(), so we have to save that somewhere. We wouldn't need that if we restricted tls_init_connection (and tls_deinit_connection) to the current object. I see no reason why it should be possible to call that on another object. |
|
|
We call tls_init_connection() in the master object in connect(), clone the login object and return it from connect(). Given the documentation of TLS in the driver, that seems to be a sane way to handle things. But this seems to be a special case, because the callback is setup into the object received from the master, while in other cases the callback is setup in tls_init_connection() itself. So I also have no compelling reason why it should possible to specify another object. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-02-25 14:42 | zesstra | New Issue | |
| 2010-02-25 15:31 | Gnomi | Note Added: 0001745 | |
| 2010-02-25 15:52 | zesstra | Note Added: 0001746 | |
| 2011-02-23 22:02 | zesstra | Target Version | => 3.3.721 |
| 2021-04-16 20:46 | zesstra | Assigned To | => zesstra |
| 2021-04-16 20:46 | zesstra | Status | new => confirmed |
| 2021-04-16 20:46 | zesstra | Project | LDMud 3.3 => LDMud 3.6 |
| 2021-04-16 20:46 | zesstra | Category | Implementation => General |
| 2021-04-16 20:47 | zesstra | Assigned To | zesstra => |
| 2021-04-16 20:47 | zesstra | Product Version | 3.3.719 => |
| 2021-04-16 20:47 | zesstra | Target Version | 3.3.721 => |
| 2022-10-06 18:16 | Gnomi | Assigned To | => Gnomi |
| 2022-10-06 18:16 | Gnomi | Status | confirmed => assigned |
| 2022-10-06 18:16 | Gnomi | Status | assigned => resolved |
| 2022-10-06 18:16 | Gnomi | Resolution | open => fixed |
| 2022-10-06 18:16 | Gnomi | Fixed in Version | => 3.6.3 |
