|
Notes |
|
|
(0015114)
|
|
Konar6
|
|
2016-06-26 00:00
|
|
|
IIRC allowing only logged-in players to connect was declined. |
|
|
|
(0015116)
|
|
Fused
|
|
2016-06-26 08:46
|
|
|
Why would it be declined? I can really understand this being wanted as future mods could have features that really needs players to login. |
|
|
|
|
Allow logging in as part of the connection sequence is a reasonable thing and I wouldn't mind having it (only allowing logged-in players to connect is a different story though, the current mechanism to prevent unauthenticated clients from joining the game should be sufficient).
A requirement for this to work is a way to feed the login credentials to the client though (I'd prefer if the launcher somehow hands the credentials over). This came up in other tickets in the past, but we never finalized anything. Any suggestions? |
|
|
|
|
> only allowing logged-in players to connect is a different story though, the current mechanism to prevent unauthenticated clients from joining the game should be sufficient
The particular use-case I was thinking of was for Private CTF. Instead of handing out a password, I could simply ban everybody and whitelist only specific usernames that are allowed to connect. |
|
|
|
|
|
Update: I made some experiments with the Windows Data Protection API and now have code that encrypts and decrypts strings under Windows. This should be safe enough to have Zandronum store the password. |
|
|
|
|
|
Another update: I scratched the DPAPI approach and instead store the credentials in the Windows Credential Manager. That's hopefully secure enough, at least it's not less secure than the DPAPI approach since all user programs have access to both mechanisms. |
|
|
|
(0015298)
|
|
Dusk
|
|
2016-07-12 20:19
|
|
|
The commits were based off the HITTARGET/etc commits for ticket 0002445, so I closed the head, and transplanted the commits to bookmark store-logins-2763. |
|