View Issue Details

IDProjectCategoryView StatusLast Update
0000730LDMud 3.6Generalpublic2022-10-06 18:16
Reporterzesstra Assigned ToGnomi  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Fixed in Version3.6.3 
Summary0000730: static logon() function does not work for TLS logon callback
DescriptionFor 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.
TagsNo tags attached.

Activities

Gnomi

2010-02-25 15:31

manager   ~0001745

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.

zesstra

2010-02-25 15:52

administrator   ~0001746

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.

Issue History

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