Feature Request: Be able to restrict access to server if not connecting with a brand new save file. #43
Comments
Is that how it works? Have you tested this? Though someone with a non-100% savefile could collect moons in later kingdoms while connected to your server. Preventing this is likely very difficult, because the client or server would need to know which moons are collectible under which conditions and you would need to tell the server somehow to limit it on your specific players progress and not that of other players. Limiting connections based on existing moon count seems impossible, without changing the SMOO communication protocol between client and server, because the server afaik doesn't get to know the total moon count of the players, but only what they collect on it (and what the server sends to them from others). Even if it would keep track of it, you'd also need to persist it somehow, otherwise a server crash/restart would prevent even you from rejoining the server again once you collected a single moon. Another approach could be to require all clients to start in Cap Kingdom with a brand new save (starting with the first scenario). This is something that is already detected by the server and kept in the metadata for each player, to prevent sending them moons before reaching Cascade Kingdom. But the metadata doesn't survive server restarts currently, so you shouldn't make block decisions based on it (same reason as in the last paragraph). Maybe a kingdom block feature could be feasible for your use case. Before your stream you block all kingdoms but Cap Kingdom. When someone sends a game packet for another kingdom (tries to load into it), they get kicked of the server (with a game crash). Before YOU enter the next kingdom, you can manually execute a server command to unlock the next kingdom for everyone. |
Sorry for the very late reply as I kinda fell out of SMOO but am looking to get back in and revisit my stream idea. That Kingdom Block feature sounds like something I could use. Is this something that I can already do or were you just suggesting it as a feature request that would satisfy my needs? Thank you. |
|
Sorry, I fat fingered the close issue button on my phone. Lol. |
That was a suggestion for a simpler/smaller feature request that would be easier to implement:
If we want to add this feature to the server permanently and not just for a one-time event, I'd suggest changing/extending the
|
|
Would stage name be its alias, and how would it work if someone connected to the server with the reconnect button(if the reconnect button miraculously)were in a subarea of a kingdom? (ex. CapWorldHomeStage is banned, but they connect inside CapWorldTowerStage) |
|
The saved stage name should be the exact name of the stage and not an alias. But the server commands should support both forms like the Blocking only based on the overworld stages should be enough to block most possible abuses. Because loading into the game, traveling with the odyssey or using a picture teleport will all load you into an overworld stage. SmoOnlineServer/Shared/Stages.cs Lines 33 to 50 in d8c59f7 But as you mentioned only-connecting when already in a sub-area of a blocked kingdom could be a way around it (but they can't get out without disconnecting first). Though we could also block/unblock all sub-areas when blocking a kingdom based on an alias. The data which stage is part of which kingdom is already there (in my PR): SmoOnlineServer/Shared/Stages.cs Lines 75 to 249 in d8c59f7 |
To kick players from the server when they enter a banned stage. <stage-name> can also be a kingdom alias, which bans/unbans all stages in that kingdom. Because we aren't banning the player, d/c them would be no good, because of the client auto reconnect. Instead send them the crash and ignore all packets by them until they d/c on their own. This is an alternative solution for issue Sanae6#43.
|
I've implemented a solution for this in PR #48. A new release w/ docker image and binary files based on |
This is so amazing of you to do. Thank you. I'll try and test it out here soon. What do you think the likelihood is that your changes will be put into the main server? |
IDK. Except for the The I'm not even sure if there ever will be an official The sporadic development focus currently seems to be on SMOO 2.0, which will likely make this repository obsolete. |
* rename command: `ban ...` => `ban player ...` To enable adding other subcommands starting with `ban`. Moving ban list and crash related code into its own class to tidy the Program class up. Change Id values of the crash cmds, to fit into the 16 byte max length imposed by ChangeStagePacket.IdSize. * add command: `ban ip <ipv4-address>` To add an IPv4 address to the ban list. * add command: `ban profile <profile-id>` To add a profile ID to the ban list. * add command: `unban ip <ipv4-address>` To remove a banned IPv4 address from the ban list. * add command: `unban profile <profile-id>` To remove a banned profile ID from the ban list. * add commands: `ban enable` and `ban disable` To set the value of `BanList.Enabled` to `true` or `false` without editing the `settings.json` file. * add command: `ban list` To show the current ban list settings. * fix: actually working ban functionality Changes: - ignore new sockets from banned IP addresses way earlier. - ignore all packets by banned profiles. Intentionally keeping the connection open instead of d/c banned clients. This is to prevent endless server logs due to automatically reconnecting clients. Before: Reconnecting clients aren't entering `ClientJoined` and therefore the d/c is only working on first connections. Effectively banned clients got a d/c and then automatically reconnected again without getting a d/c again. Therefore allowing them to play normally. * use SortedSet instead of List for settings To enforce unique entries and maintain a stable order inside of the `settings.json`. * add commands: `ban stage <stage-name>` and `unban stage <stage-name>` To kick players from the server when they enter a banned stage. <stage-name> can also be a kingdom alias, which bans/unbans all stages in that kingdom. Because we aren't banning the player, d/c them would be no good, because of the client auto reconnect. Instead send them the crash and ignore all packets by them until they d/c on their own. This is an alternative solution for issue #43. * Update Server.cs --------- Co-authored-by: Sanae <[email protected]>
|
It was merged and is part of the new 1.0.4 release from today. |
To kick players from the server when they enter a banned stage. <stage-name> can also be a kingdom alias, which bans/unbans all stages in that kingdom. Because we aren't banning the player, d/c them would be no good, because of the client auto reconnect. Instead send them the crash and ignore all packets by them until they d/c on their own. This is an alternative solution for issue Sanae6#43.
|
I've been thinking about this for a couple weeks, and wanted to throw out an idea. It's not complete yet, but I think it's far enough along to give the general idea if you check out my fork at https://github.com/ktmitton/SmoOnlineServer In this, I set up the TCP server to work within the asp.net lifecycle as a HostedService, and I split the work into three different projects:
Using this approach, I think it gives us the following benefits:
Number 3 in particular addresses this issue because we could implement an ILobby, or update the current Coop lobby, so it could auto-track the "leader", unlocking zones as the leader unlocks it. So auto-manage the banned stages list, but without needed to adjust how the basic connection code works, dependency injection handles the magic of getting the received data where it needs to go. What do you think? |
|
Oh, running in the asp.net lifecycle, it can also make docker images smaller because we should be able to just leverage the basic microsoft alpine images, and they'll automatically start up the webserver. |
The short summary is I would like it if I could have an option in the settings to make it so that only people with 0 power moon will be able to connect.
Long story is I am planning on doing a stream on Twitch where I try to collect all 999 power moons and would like it if random people could join me and help me in my quest. What I don't want is for people to connect to my server with a save file that is later in the game than I am currently at and have them sync power moon to me in areas that i shouldn't have access to yet. My idea for this is to have the server check how many power moons a person has and if it's a number greater than 0 then it will refuse the connection. This way when random people join me, once they connect with their brand new save file, all power moons will be synced to them. The only thing a new person has to do to quickly catch up to where I am at is to enter each kingdom and throw cappy on the odyssey.
I know nothing about coding or how any of this works so this is just an idea on how I think it could work. If anyone else has any better ideas or the knowhow to make it happen, I would really appreciate it. Thanks.
The text was updated successfully, but these errors were encountered: