wiz0u / WTelegramClient

Telegram Client API (MTProto) library written 100% in C# and .NET
https://wiz0u.github.io/WTelegramClient/
MIT License
956 stars 156 forks source link

Client.User field is not updated during the session, can be harmful #239

Closed CaCTuCaTu4ECKuu closed 6 months ago

CaCTuCaTu4ECKuu commented 6 months ago

Regarding of "as designed" from #107 Technically okay, but this field is literally one of few properties of Client and is asking to be used when interacting with instance. Especially when restoring from session, which is designed behavior, I didnt find any way to fill it or force to synchronize Also what will happen if user info changes while using client, I suppose Client.User stays as it was when authorized

I want to say that this field is harmful and confusing (I myself just spend few hours figuring that why it's null when restoring session) and it must be removed or hidden as LoginIfNeeded returns corrent information, but rather Client must have dedicated method like getSelf that will return actual current user and shorted using of Client.Users_GetUsers(InputUser.Self), moreover it's much more obvious without search on closed github issues

wiz0u commented 6 months ago

client.User is necessary for the alternate simplified login method, as shown in the README It will not be saved in session file, by design, as previously said. It is only filled by Login or LoginUserIfNeeded (documented in its Intellisense doc)

You're right that its content is not updated during the session if the user change something, but its access hash is always correct if you want to use it while interacting with the instance API. And as you noted, you can use GetUsers(InputUser.Self) for retrieving an updated version, or just watch the new user structure received on UpdateUser updates notifications.

I don't plan to provide a GetSelf for such an easy API call.

CaCTuCaTu4ECKuu commented 6 months ago

I see, but can argue about necessary of exposing User in public, moreover if it's only purpose it is authorization I believe it should be removed and wrapped withing authorization operation. Regarding access hash it looks like it should be put in there instead of User. Of course library is already widely distributed and removing property can be harmful for people already using it, but consider this - if marked with deprecated for now, people will pay attention about using this property in their code after authorization