Feature request: BungeeCord/Waterfall support

[bigfinfrank]

Is your feature request related to a problem? Please describe. As the plugin doesn't currently support BungeeCord or it's popular fork Waterfall, it's currently not possible to pick and choose connections to block from plugins placed in a server's proxy. This is rather upsetting as many plugins with Bungee versions that include the functionality Network Interceptor aims to block like unnecessary update checking and automatic updates have this same (in some cases) malicious functionality in the BungeeCord variants of their plugins, one example of this is PremiumVanish (the same functionality is probably present in SuperVanish).

Describe the solution you'd like I'd like for the plugin to have BungeeCord support or at least have an official Bungee version of the plugin available. I vaguely remember some plugins requiring functionality that is present in Waterfall and not BungeeCord in which case it would be nice to also use the functionality available through Waterfall (when available) if it would compliment the experience, somewhat similarly to how the security manager method is better compared to proxy-selector but it's not possible to use it in every scenario. It would be ideal for simplicity's sake to have the Bungee version of the plugin bundled in the same jar for neatness on the user's end if possible, but that's definitely a nit-picky preference thing.

Describe alternatives you've considered I've tried using external solutions but they can't give stack traces and are generally harder to use. It's also quite difficult to find the culprit for a certain unwanted connection in some cases and when you do sometimes it's not possible to block only that functionality as many plugins use Cloudflare and therefore the same set of proxied host IPs.

Additional Context N/A

[bigfinfrank]

Because I clean my logs files out-of-band (in my server start-up script), I didn't notice that NetworkInterceptor appends to intercept.log. Unless I am mistaken, we should add a configuration option to truncate it on start-up, true by default. Something like

• logging.truncate-on-start: true

It might be best to create a separate issue for this, but I'll let you be the judge of that. May I suggest an option to use the gzip-and-date-old-logs system used by Spigot? This effectively resets the log on startup while still preserving it for reference as opposed to just clearing it. However I'm not sure how difficult it would be to implement this.

[SlimeDog]

I don't know if it's possible, but it would be nice if the command name and the subcommand names didn't have to change. There is no confusion between server commands and bungee commands, afaik -- they operate in different universes. The same abbreviation (ni) would also be nice. But I await the implementer's evaluation.

[SlimeDog]

May I suggest an option to use the gzip-and-date-old-logs system used by Spigot? This effectively resets the log on startup while still preserving it for reference as opposed to just clearing it. However I'm not sure how difficult it would be to implement this. I think NetworkInterceptor already has such a system. I have seen

• intercept.log
• intercept.log.1
• intercept.log.2
• intercept.log.3
• intercept.log.4

before I started removing them (actually, my start-up process saves a copy of the last one in a temporary directory, along with other items I want to save for review). If the process already exists, it is not active in Bungee.

[bigfinfrank]

I don't know if it's possible, but it would be nice if the command name and the subcommand names didn't have to change. There is no confusion between server commands and bungee commands, afaik -- they operate in different universes. The same abbreviation (ni) would also be nice. But I await the implementer's evaluation.

BungeeCord commands are passed on to players, I'm not sure as to whether or not this is avoidable however an example that I've previously referenced is LuckPerms' lpb command. A default example you can see for yourself is /server which is a default BungeeCord command.

EDIT: To clarify, this means that the player would be executing either the spigot OR bungee command if they had identical names.

[SlimeDog]

@bigfinfrank Are you a Windows user? If so, I have a request. I use a Linux script that summarizes the log. I intend to add it to the Overview and the wiki. It would be great to have the MS-DOS/Windows equivalent. The Linux script is

INTERCEPT_LOG_FILE="plugins/NetworkInterceptor/intercept.log"
grep --text -e 'Current .* version:' ${INTERCEPT_LOG_FILE}
grep --text -e Intercepted -e Blocked ${INTERCEPT_LOG_FILE} | sed -e 's/.*Intercepted/Intercepted/' -e 's/.*Blocked/Blocked/' | sort -u

[SlimeDog]

BungeeCord commands are passed on to players, I'm not sure as to whether or not this is avoidable however an example that I've previously referenced is LuckPerms' lpb command. A default example you can see for yourself is /server which is a default BungeeCord command.

Yes, but -- for example -- ProxyWhitelist runs commands on the bungee instance, without reference to the servers.

[bigfinfrank]

@bigfinfrank Are you a Windows user? If so, I have a request. I use a Linux script that summarizes the log. I intend to add it to the Overview and the wiki. It would be great to have the MS-DOS/Windows equivalent. The Linux script is

INTERCEPT_LOG_FILE="plugins/NetworkInterceptor/intercept.log"
grep --text -e 'Current .* version:' ${INTERCEPT_LOG_FILE}
grep --text -e Intercepted -e Blocked ${INTERCEPT_LOG_FILE} | sed -e 's/.*Intercepted/Intercepted/' -e 's/.*Blocked/Blocked/' | sort -u

For server hosting I am not and I don't have much batch or powershell scripting knowledge (I just use bash scripts through WSL), sorry.

[mart-r]

I'm currently on my phone so sorry for the short response.

Right now, trusted plugins do not work work bungee. This is because there is no simple way to find a plugin that is responsible for a class like there is on Spigot. Or at least I don't know if one. Edit: these mostly have a TODO comment on them unless I forgot to push the latest code

As for the bungee/waterfall issue, there might be a way to hack the security manager to work on bungee. I've coded something for that ( on a different breach) but since the were other issues, I didn't include it yet. With that said, if it's not possible, catching the exception and showing a message would be rather trivial.

And right now the command doesn't work on bungee, but I shouldn't be difficult to address that.

PS. I will be home later today and will try to address what I can.

[SlimeDog]

PS. I will be home later today and will try to address what I can.

There is a lot to swallow (above). I would be happy to provide a summary of my understanding of outstanding issues. We can take that over to our development chat. But it's late here (even later for Frank) -- I'm crashing for the night.

[bigfinfrank]

Yes, but -- for example -- ProxyWhitelist runs commands on the bungee instance, without reference to the servers.

Forgive me if I'm misunderstanding you here but I believe the reason that's possible is because whitelisting is being done at the proxy level and there isn't a Spigot plugin that could also need to to be controlled. In that case all commands are handled by the Bungee plugin. In NetworkInterceptor's case because there could (and probably would) be a copy of the plugin present on both Bungee and within Spigot, there is still a need for admins to be able to separately address the Spigot and Bungee plugins.

---

I'm also going to head to sleep now, definitely lost track of time.

[SlimeDog]

My understanding is that ProxyWhitelist operates on the Bungee instance, and has no impact on the servers. I could be mistaken, but I don't believe that any commands are sent to the servers. The servers utilize the vanilla MC whitelist commands, but could as easily utilize a plugin (there are many -- I don't know why, since the vanilla whitelist commands work fine) without knowledge of the upstream whitelist.

ServerListPlus operates similarly.

[bigfinfrank]

My understanding is that ProxyWhitelist operates on the Bungee instance, and has no impact on the servers. I could be mistaken, but I don't believe that any commands are sent to the servers. The servers utilize the vanilla MC whitelist commands, but could as easily utilize a plugin (there are many -- I don't know why, since the vanilla whitelist commands work fine) without knowledge of the upstream whitelist.

ServerListPlus operates similarly.

• ProxyWhitelist introduces it's own system that works separately from (but with identical syntax to) the vanilla MC whitelist command, you can test this by whitelisting someone from the BungeeCord console, checking the Spigot whitelist.json (there will be no change), and checking the \plugins\ProxyWhitelist folder for the player's name in one of the files saved there.
• ServerListPlus works similarly to ProxyWhitelist in the aspect that there would only be one "instance" of the plugin active at one time. This could either be on (if applicable, each of) the Spigot server(s) assuming Bungee is configured with ping_passthrough: true (as this also enables MOTD passthrough, see here for more details). The other way which I would assume is the generally preferred way (it's the configuration I would prefer) is to have ServerListPlus only running under Bungee as a Bungee plugin.

Non-technical explanation (from my understanding and experience):

Try to think of the players as people, the spigot servers also as people, and Bungee as the messenger. All the people (players and spigot servers) can write letters (packets), but they need to be brought to their destination by the messenger (Bungee). The messenger (Bungee) can open up these letters, look inside, and change them (write new stuff/erase stuff/rewrite stuff - stuff = data) or just refuse to deliver them altogether. The Bungee plugins are like the messenger's friends, they can ask the messenger if they can look in as well (ex. by registering a command) and make changes if they want to (ex. handling a command for their plugin).

The more technical explanation that's much longer (again from my understanding and experience) goes as follows:

This is all possible because Bungee commands aren't sent to the servers, actually directly to the players. This is possible because when connecting to a Bungee network you connect to the proxy (Bungee/Waterfall) which then forwards data (spigot -> bungee -> player and player -> bungee -> spigot), Bungee effectively works as a middle man for the Spigot backend and the player. My understanding is that BungeeCord commands are injected into whatever packet(s) hold command information. Similarly, when getting command packets from the player, BungeeCord (and it's plugins) get to read the data before Spigot by design and act based upon it before the Spigot server ever sees it (meaning it can execute a command if found and not send the command to Spigot). This means that if a command matches one of BungeeCord's (or a Bungee plugin's), that would be executed and the command wouldn't be forward to the Spigot server, making a command with an identical name inaccessible without namespaces (as I don't think BungeeCord handles namespaced commands, I'm not sure of this though). You can test this fairly simply by using the default /server command in-game, your Spigot server console won't show anything being run in however your BungeeCord's console will because it was effectively 'intercepted' by BungeeCord. This could very well be incorrect from a technical aspect but I've never seen anything in practice from my experience to contradict this and the workarounds I've seen used seem to support this understanding. The only plugins placed on both Spigot and Bungee that I've seen where both can be controlled simultaneously either use the more common approach of renaming the Bungee command or they use a more advanced and complicated approach where the two plugins 'talk' to each other instead of having the Spigot plugin listen for the command (because they know that Bungee will act upon the command first and cancel it being sent to Spigot). The latter approach typically requires use of BungeeCord's plugin messaging system or the existence of a database both plugins are connected to.

I don't have a perfect technical grasp of how BungeeCord works I just know what I've heard and what makes sense based on what I've seen and done. One thing I do know is that commands that are registered on Bungee will first be handled by Bungee and it logically doesn't make sense for a player issuing one command to trigger an action from two separate plugins (even if they're the same plugin, they're different 'instances' of that plugin, one on Spigot and one on BungeeCord) because that could be both confusing for the end user and it would just generally be messy. Sorry for making this so long.

EDIT: Mart will probably be able to figure this out concretely if he tries to keep the command name identical, in that case I believe that it won't be possible to interact with the Spigot plugin.

[SlimeDog]

My understanding: Your explanation(s) are true of many (perhaps most) Bungee plugins, but not plugins like ProxyWhitelist or NetworkInterceptor, which do not interact at all with server instances (and therefore, not with players on those servers).

[bigfinfrank]

My understanding: Your explanation(s) are true of many (perhaps most) Bungee plugins, but not plugins like ProxyWhitelist or NetworkInterceptor,

You can whitelist people with ProxyWhitelist from in-game as a player, that is an interaction. The Spigot server doesn't have any knowledge of this interaction because it's intercepted by Bungee before Spigot is told about it (and Bungee doesn't tell Spigot that this interaction ever happened because it doesn't concern Spigot if a Bungee plugin has already acted upon the command). Unless I am incorrect in assuming that players can interact with NetworkInterceptor via commands in-game, then shouldn't my explanation also apply to NetworkInterceptor (and for that matter, any Bungee plugin that uses commands)?

which do not interact at all with server instances (and therefore, not with players on those servers).

I'm assuming that by server instances you mean Spigot servers here. I'd like to point out that it is not necessarily true that just because the Spigot server isn't aware of the exchange doesn't mean that players aren't interacting with Bungee. Bungee is in the middle of the exchange here, not Spigot. Bungee can 'talk' to the player without Spigot knowing and Spigot can 'talk' to Bungee without the player knowing (however, players can not talk with the Spigot server without Bungee knowing*).

*This is assuming there isn't a plugin exposing a method for players to do this (which would be dangerous) and that the network has their backend Spigot servers properly secured with firewall rules configured correctly. Tl;DR this is assuming that the intended/expected BungeeCord dynamic is preserved.

The servers utilize the vanilla MC whitelist commands, but could as easily utilize a plugin (there are many -- I don't know why, since the vanilla whitelist commands work fine)

This was a bit old of a comment and isn't necessarily on-topic but I thought that I could provide context for why this is useful. Lets say you're hosting a basic creative and a basic survival server that are bridged together with BungeeCord or Waterfall. Without ProxyWhitelist (or an equivalent plugin), if you wanted to use a whitelist system you would need to whitelist each player twice (and in the situation where you wanted to remove them, you'd also need to do that twice) because the vanilla whitelist system only locally affects that Spigot server. You'd be running /whitelist add Player first on the survival Spigot server then a second time on the creative Spigot server. ProxyWhitelist aims to centralize this by handling whitelisting on BungeeCord, before the survival or creative spigot servers are involved.

[SlimeDog]

I am still learning. Thanks for the detailed explanations.

I cannot think of a good reason for a player to interact with the Instance of NetworkIntercepter on Bungee. WRT ni reboot, they would do that on the Bungee server, after having edited the configuration. I suppose they could want to get ni info about the instance running on the Bungee server, but I don't see a reason; they would just execute it on the Bungee server. So I am confused.

ProxyWhitelist aims to centralize this by handling whitelisting on BungeeCord, before the survival or creative spigot servers are involved.

I understood that to be the case. I assumed that the ProxyWhitelist commands were executed on the Bungee console. From your explanation, it sounds like they could also be executed, and transmitted to the Bungee server, on a Spigot server. Is that correct? Is that why different plugin names/commands are required?

[bigfinfrank]

I am still learning. Thanks for the detailed explanations.

No problem, I'm happy to help.

I cannot think of a good reason for a player to interact with the Instance of NetworkIntercepter on Bungee. WRT ni reboot, they would do that on the Bungee server, after having edited the configuration. I suppose they could want to get ni info about the instance running on the Bungee server, but I don't see a reason; they would just execute it on the Bungee server. So I am confused.

If the commands are registered on Bungee, that would mean the Spigot plugins' command would never work because from Bungee's perspective a player ran ni which was registered by the Bungee plugin. This is means that Bungee then tells the Bungee plugin that the command was run with whatever arguments were supplied, and doesn't tell the Spigot server (and therefore not telling the Spigot plugin) because as far as Bungee is aware, that command will now be processed (and it will, just only by the Bungee plugin). Keep in mind that Bungee itself doesn't care what plugins/commands are present on the Spigot server so it's ignorant to the fact that there is a Spigot plugin with the same command registered. Bungee is only concerned with handling it's responsibility to Bungee plugins and forwarding data.

---

I'll respond to this next section in small parts for clarity.

I understood that to be the case. I assumed that the ProxyWhitelist commands were executed on the Bungee console.

Commands can be input from both the Bungee console and through in-game chat (assuming permissions are met). On the topic of permissions it's worth mentioning that Bungee does not care nor does it necessarily have information about the default OP system present on Spigot servers. Instead, Bungee uses it's own permissions system or the one given by a permissions plugin like LuckPerms-Bungee. The default permissions are customizable by editing your Bungee/Waterfall config.yml and restarting the proxy (if it wasn't yet clear, proxy is the general term for a Waterfall or BungeeCord instance as it works as a proxy between the player and Spigot servers).

From your explanation, it sounds like they could also be executed, and transmitted to the Bungee server, on a Spigot server. Is that correct?

That is correct except for one particular distinction that you need to keep in mind, while the player seems to be connected to the Spigot server, they really are connected to Bungee which relays the Spigot server to the player (and vice versa). In reality the Spigot server takes no part in Bungee commands, even if a user executes them from in-game in what appears to be a Spigot server, because Bungee intercepts the command before Spigot sees it and it doesn't forward on the command as it's already being handled by a Bungee plugin (or if it's a default Bungee command, by BungeeCord itself). This is how players can change what Spigot server they are connected to within a Bungee network using the BungeeCord /server command. If you're familiar with mini-game servers this is also how players can move to a different lobby with a command, they're asking Bungee to send them to a different Spigot server.

Is that why different plugin names/commands are required?

Yes this is why different command names are required unless you want to do a (probably complicated) solution with plugin messaging where the Bungee version of the plugin communicates with the Spigot version (I recommend against this as it isn't standard and may cause confusion for players that are familiar with the standard of a differently named bungee command). Different plugin names are (to my knowledge) not required. Additionally, as far as I'm aware Bungee doesn't support namespaced commands (/namespace:command). The Bungee start-up message for plugins being enabled shows the name of the LuckPerms bungee plugin as simply LuckPerms which is also the case for the Spigot (bukkit) version of LuckPerms. LuckPerms Bungee is accessible through /lpb and LuckPerms Spigot (bukkit) remains accessible through the normal /lp- typically these would both be connected to the same database for unification in a proper network.

[SlimeDog]

thanks again. Given that (IMO) there is no reason for a player to execute proxy NI commands, is there a reason to expose them? If not, then ni on a server would execute NetworkInterceptor server commands (on the server). On a proxy, ni would execute NetworkInterceptor proxy commands (on the proxy console). Or is that a potential confusion from which you are trying to steer me away?

[bigfinfrank]

thanks again. Given that (IMO) there is no reason for a player to execute proxy NI commands, is there a reason to expose them? If not, then ni on a server would execute NetworkInterceptor server commands (on the server). On a proxy, ni would execute NetworkInterceptor proxy commands (on the proxy console). Or is that a potential confusion from which you are trying to steer me away?

If they are named identically then running ni anywhere except for the Spigot console would result in the proxy command being run. The only way I'm aware of to get around this is having people run the namespaced command networkinterceptor:ni to interact with the Spigot plugin. If that's the approach taken personally I feel like it's simpler to just name the command nib // networkinterceptorbungee. And yes that is the confusion I'm trying to steer you avoid, less experienced users can find it difficult to know which plugin they're interacting with in the same way it's a bit confusing to understand how Bungee and Spigot servers interact.

[SlimeDog]

So "universal" resources have two command sets?

Got it. Thanks.

[SlimeDog]

If I (finally) have absorbed the above (still a questionable assertion), then I understand there to be two regular approaches:

• one universal resource
  • if installed on Spigot/Paper
  • main command: networkinterceptor
  • alias: ni
  • proxy command: networkinterceptorproxy
  • alias nip
  • if installed on Bungee/Waterfall
  • main command: networkinterceptorproxy (so tab-completion still works as expected) at the console
  • alias: nip
• two separate resources
  • NetworkInterceptor-.jar for Spigot/Paper
  • main command: networkinterceptor
  • alias: ni
  • NetworkInterceptorProxy-.jar for Bungee/Waterfall
  • main command: networkinterceptorproxy (so tab-completion still works as expected)
  • alias: nip

In either case, how is the proxy command registered on the server, so that a player can execute it, or does that all happen automagically behind the scenes?

[bigfinfrank]

The typical approaches would be more like this:

• One universal resource

  • if installed on Spigot/Paper

  • main command: networkinterceptor

  • alias: ni

  • if installed on Bungee/Waterfall

  • main command: networkinterceptorbungee

  • alias: nib

• Two separate resources:

  • For Spigot/Paper:
    • main command: networkinterceptor
    • alias: ni

  There are two popular jar formats:

  • NetworkInterceptor-.jar

    and

  • NetworkInterceptor-Spigot-.jar If Bukkit is supported this would be NetworkInterceptor-Bukkit-.jar instead. You typically go to the farthest upstream compatible platform)

  • For Bungee/Waterfall:

    • NetworkInterceptor-Bungee-.jar Proxy could refer to Velocity which is completely separate from Bungee and does not have Bungee plugin support. Velocity is it's own entirely different platform with similar functionality, still serving the purpose of a proxy.

    • main command: networkinterceptorbungee

    • alias: nib

In either case, how is the proxy command registered on the server, so that a player can execute it, or does that all happen automagically behind the scenes?

The way I edited your example above is how they would be registered, Bungee handles showing it to players as well as execution (standalone Bungee plugins that register commands without Spigot counterparts are evidence of this). Proxy commands on the proxy, Spigot commands on Spigot- registering the same command twice results in the same issues we're trying to avoid by changing the Bungee command to nib instead of ni. Tab completion should still work as expected- the tab completion added by Waterfall is console tab completion, normal tab completion is still present with BungeeCord when executing commands in-game as far as I'm aware. I think that Bungee would just intercept the tab completion anyways so registering it twice (using Spigot for tab completion) wouldn't even be a functional workaround (I'm not 100% sure of this though).

Personal opinion here; If there are two separate resources made after a plugin's initial publishing, I believe it's best to name the Spigot/Paper resource according to the first popular format. This is because that's how it's already named and it could mislead users into thinking that this was a new split and old jars were universal. The one con to this however is that some people may be mislead by this as well, thinking that they need to download the Spigot and Bungee specific jars separately from the normal resource. I believe that people in the second group are less common and I haven't seen as many people asking this in support channels but I have seen it once or twice in the past.

So "universal" resources have two command sets?

Got it. Thanks.

That is correct, one registered by Spigot for the spigot commands and one registered by Bungee for the Bungee commands (and aliases also registered based on their respective platform).

[SlimeDog]

If there are two separate resources made after a plugin's initial publishing, I believe it's best to name the Spigot/Paper resource according to the first popular format. I interpret that to mean:

• since NetworkInterceptor-\<version>.jar has already been released (in 2018 and again this week), we should stay with that name for the Spigot/Paper JAR
• we should go with NetworkInterceptor-Bungee-\<version>.jar for Bungee/Waterfall

[bigfinfrank]

I interpret that to mean:

• since NetworkInterceptor-\<version>.jar has already been released (in 2018 and again this week), we should stay with that name for the Spigot/Paper JAR
• we should go with NetworkInterceptor-Bungee-\<version>.jar for Bungee/Waterfall

That's exactly right.

[SlimeDog]

See, it does sink in, eventually. 😎

[bigfinfrank]

I'd just like to leave the idea of Velocity support out there as another (albeit less popular) platform, from what I've heard there are a few large networks that have adopted it and it's growing in popularity. It is (from my very limited understanding), an entirely different platform from Bungee so I'll leave this for another day.

[SlimeDog]

Please open a separate ticket. Way outside the scope of this one.

[mart-r]

Uploaded v2.0.0-Bungee-5: \<LINK ELIDED>

EDIT: Changes:

• Attempting to fix SecurityManager for Bungee (untested)
• Added command to Bungee (bungeenetworkintercept or bni)
• Fixed Bungee authors
• Added config entry that allows clearing the log file upon a restart

[mart-r]

Uploaded v2.0.0-Bungee-6. \<LINK ELIDED> Changes:

• Revered the attempt at a security manager fix and instead catching the exception and letting the user know that this functionality is not available on Bungee.
• Now using suffix not prefix for the bungee command.

[SlimeDog]

To help inure us to the way it will be, please remove the "Bungee-" reference from the internal version string and file name, given that there is really only one (universal) JAR.

The next build should be 2.0.1 for testing, in preparation for release 2.1.0 (or do you think we should bump the MAJOR?).

[mart-r]

Uploaded v2.0.1: \<LINK ELIDED>

[SlimeDog]

I'm thinking that the default should be true for intercept.log truncation, but that's just me. Open to being persuaded otherwise.

Otherwise, I think 2.0.1 is golden. Anyone seeing issues with it, or should we get this out the door?

[mart-r]

I'm thinking that the default should be true for intercept.log truncation, but that's just me. Open to being persuaded otherwise.

I've made the changes and pushed 2.0.2: \<LINK ELIDED>

[SlimeDog]

I pushed the relevant change to the three configuration files in branch bungee. Please pull them and build 2.0.3. Thanks.

[mart-r]

Uploaded 2.0.3 \<LINK ELIDED>

[SlimeDog]

Confirmed configuration updates in 2.0.3. Thanks.

[bigfinfrank]

Otherwise, I think 2.0.1 is golden. Anyone seeing issues with it, or should we get this out the door?

I haven't run into any issues, I can do a production test for a day before release if you'd like.

[SlimeDog]

Thanks. I will ask you to do that, in addition to my own feature-set tests. What is your configuration, ie., which proxy and server variants? I will cover the others -- Spigot, Paper, BungeeCord, and Waterfall.

We have one remaining issue. After that is sorted, I will ask for a source merge and release build. I am inclined to go with 3.0.0, based on Bungee/Waterfall being major feature update. I could be convinced that 2.1.0 (ie., minor update) is OK, if either of you feel strongly.

Change log:

• BungeeCord/Waterfall support
• Configuration additions
  • config.yml
  • logging.truncate-file-on-start: true
  • sample-allow-config.yml
  • mcstats.spigotmc.org added to default allowed targets
  • logging.truncate-file-on-start: true
  • sample-deny-config.yml
  • logging.truncate-file-on-start: true
• Trucate intercept.log on server restart or plugin reload

[SlimeDog]

BTW, I am successfully connected to my Spigot test server through a Waterfall proxy (I can also switch the server or the proxy to the other variants). The configuration is probably not exactly right for prime-time, but it's adequate for testing.

[bigfinfrank]

Thanks. I will ask you to do that, in addition to my own feature-set tests. What is your configuration, ie., which proxy and server variants? I will cover the others -- Spigot, Paper, BungeeCord, and Waterfall.

I run Purpur, a downstream fork of Paper (I will secondarily check any issues I run into on a Paper server as well but they shouldn't have very different functionality) and in terms of proxy I run Waterfall. I will be running the same config.yml on both my proxy and backend servers, you can find mine here. I've added my findings from intercept.log and other resources to my config- you are free to add some them to the default config.yml if you wish, they are all somewhat documented.

I am inclined to go with 3.0.0, based on Bungee/Waterfall being major feature update. I could be convinced that 2.1.0 (ie., minor update) is OK, if either of you feel strongly.

I'm personally indifferent to this so that's up to you and Mart.

---

Additionally I noticed that it logging.truncate-file-on-start wasn't added to my config.yml automatically, if this is expected then it's probably a good idea to mention that this needs to be added manually in the changelog.

[SlimeDog]

Thanks for the configuration example. I will have a look, and decide if anything needs to be added to the samples and default (deny) config.yml.

As a matter of principle, my plugins do not alter configuration files. I do provide sensible defaults (in this case: true).

I will add a note to the changelog that configuration changes need to be addressed manually. (For 2.0.0, this was essential given the differences from 1.0, so well-documented.)

[mart-r]

I've just realized I never addressed the Bungee plugin detection issue (the feature was missing from the bungee part). I've addressed that in a (experimental!) way for now. Let me know if it works. Uploaded 2.0.4: \<LINK ELIDED>

[SlimeDog]

Somehow, I didn't save all of the changes to comments in sample-deny-config.yml. I just updated them in branch=bungee. So they will be picked up next iteration. :(

[mart-r]

There were some further issues and a new version (2.0.6) is now available: \<LINK ELIDED> It should be able identify plugins on Bungee as well as Spigot.

[bigfinfrank]

Just launched 2.0.6 into prod, only thing I've noticed so far is there's a connection being made to the hostname of the server (the actual computer) and a warning following it. My server runs Debian 10 (Buster), the same message occurs on my Windows 10 Pro computer at home- it doesn't seem to be causing any issues but it might in allow mode with blocking enabled (haven't been able to test this yet though). Here's the connection message and warning:

[17:41:59 INFO] [NetworkInterceptor]: Intercepted connection to Aquarius
[17:41:59 WARN] [NetworkInterceptor]: Unable to find plugin: none

---

Another thing I've noticed is that plugin identification doesn't seem to be working on Waterfall (it does on Purpur, presumably Paper as well- I'll verify when I get home). Here's an example with the lpb editor command from LuckPerms:

> lpb editor
[17:47:04 INFO]: CONSOLE executed command: /lpb editor
[17:47:04 INFO] [LuckPerms]: User Housekeeper: unloading user data for 98274705-68b9-4021-9d42-c40228e8b41d
[17:47:04 INFO] [LuckPerms]: User Housekeeper: unloading user data for c1fd8d43-0409-4892-a301-40535ab59eb6
[17:47:04 INFO] [LuckPerms]: User Housekeeper: unloading user data for 3e4cd25a-7d02-40dd-a183-cd18ddc3d460
[17:47:04 INFO] [LuckPerms]: User Housekeeper: unloading user data for 7603d295-87de-36a4-a089-6f6f93b31376
[17:47:04 INFO]: [LP] Preparing a new editor session, please wait...
[17:47:05 INFO] [NetworkInterceptor]: Intercepted connection to bytebin.lucko.me
[17:47:05 INFO] [NetworkInterceptor]: Intercepted connection to bytebin.lucko.me
[17:47:05 INFO] [NetworkInterceptor]: Intercepted connection to 104.21.76.198
[17:47:05 INFO] [NetworkInterceptor]: Intercepted connection to 104.21.76.198
[17:47:05 INFO] [NetworkInterceptor]: Intercepted connection to bytebin.lucko.me (104.21.76.198)
[17:47:05 INFO]: [LP] Click the link below to open the editor:
[17:47:05 INFO]: https://luckperms.net/editor/redacted

[SlimeDog]

[17:41:59 WARN] [NetworkInterceptor]: Unable to find plugin: none

Check your config.yml for

trusted-plugins:
- none

Another thing I've noticed is that plugin identification doesn't seem to be working on Waterfall

That is the outstanding issue we're working on. :)

[SlimeDog]

Just launched 2.0.6 into prod

Just for the record, 2.0.6 is not accessible publicly and is not certified for release. Frank was part of the testing crew.. 3.0.0 will be available soon. Patience.

[bigfinfrank]

Check your config.yml for

trusted-plugins:
- none

It's there, should I remove it?

# Trusted plugins
# In allow mode, outbound network connections by these plugins will be allowed.
# In deny mode, outbound network connections by these plugins will be allowed,
# unless the target is explicitly blocked in the targets list.
#
# If LuckPerms is installed, we recommend listing it as a trusted plugin, to simplify configuration.
trusted-plugins:
  - none

[SlimeDog]

Yes. I think valid YAML requires either

trusted-plugins: -

or

trusted-plugins: []

I have not tested either of them, and am AFK for a few hours.

[bigfinfrank]

Yes. I think valid YAML requires either

trusted-plugins: -

or

trusted-plugins: []

I have not tested either of them, and am AFK for a few hours.

Using trusted-plugins: [] suppressed the warning, thanks.

[SlimeDog]

Using trusted-plugins: [] suppressed the warning, thanks.

Updated the three configuration files in branch=bungee. Please pull them for the next iteration.