The title is NOT a typo. This is actually what was in the console.

Which module are you submitting this issue for?

Mines

Describe the issue you are experiencing.

Some commands like /mines info only return an error and some like /mines block return the confirmation message and an error.

Describe the steps to reproduce the problem.

SPIGOT: CraftBukkit version git-Spigot-9de398a-9c887d4 (MC: 1.14.4) (Implementing API version 1.14.4-R0.1-SNAPSHOT)
PRISON: 3.1.1 (API level 3)

I really don't know how this happened, although I did find an error in the console:

[19:49:40] [Craft Scheduler Thread - 2/WARN]: [Prison] Failed to get resource info from spiget.org
java.io.IOException: Server returned HTTP response code: 403 for URL: http://api.spiget.org/v2/resources/1223?ut=1574275780699
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1894) ~[?:1.8.0_212]
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492) ~[?:1.8.0_212]
at org.inventivetalent.update.spiget.SpigetUpdateAbstract$1.run(SpigetUpdateAbstract.java:92) [Prison%20(1).jar:?]
at org.bukkit.craftbukkit.v1_14_R1.scheduler.CraftTask.run(CraftTask.java:81) [spigot-1.14.4.jar:git-Spigot-9de398a-9c887d4]
at org.bukkit.craftbukkit.v1_14_R1.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:54) [spigot-1.14.4.jar:git-Spigot-9de398a-9c887d4]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_212]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_212]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_212]

It looks like someone put spiget instead of spigot

Anything else we need to know?

Not really...

Spiget is a plugin that just checks to see if there is a newer version of the plugin available for download. They are playing off the name of the Spigot.org.

Basically the way SpigEt works is that it uses the spigOt resource id (a number) to check to see what the latest build artifact version is. It then compares it to the version that is associated with the plugin. If they don't match, then it displays a message on the console of the server.

Failure of spiget is annoying, but should not impact the functionality of the plugin.

So then, what's triggering this issue? If you are trying to build this plugin from the source, you may find in prison-spigot/build.gradle file is a resource:
include(dependency('org.inventivetalent.spiget-update:bukkit:1.4.0'))
That resource is no longer being hosted within the repsoitory and needs to be updated to the current version.

I've started to take over this project and I've forked it so I can update resources like these, plus fix a few bugs and add new functionality.

You can download build artifacts from my fork that will have this issue fixed, and a few others addressed too. https://github.com/rbluer/Prison/releases

I suggest that the build artifact from release v3.5.1 is stable for use on servers. It is identical to the v3.1.1 release but with updates to the missing libraries that are used within the plugin. No new functionality has been added to v3.5.1 and no code was altered.

I currently do not have a stable v3.5.2 release available yet, since it is in alpha. But I hope to have that ready in the next few days. I will be pushing out a newer alpha tonight that will address a few issues (mines not being randomly regenerated, they are always the same for each mine reset) plus a few other tweaks. I hope to get a few more new features added to the prison-mine module prior to the stable v3.5.2 release.

I hope that helps, and I hope you can find some value in the newer updates. Thanks greatly for reaching out and logging an issue. If you have any other issues, please let us know and I'll try to get them addressed.

Thanks,
Blue

Hi.
If this get fixed, just tell me.
Have a nice day

Gabryca its fixed in the newer releases greater than v3.1.1, such as with my fork. V3.5.1 would be a stable release with that fix.

You can download build artifacts from my fork that will have this issue fixed

@rbluer Similar errors occurred using the latest (pre-)release of your fork.

What was the stack trace that was generated from my fork? I'm guessing it was the same?

Looking at your original bug report, it had indicated there was a 403 (forbidden) exception when accessing http://api.spiget.org/v2/resources/1223?ut=1574275780699

Are you able to access that URL from your browser? It should give you a JSON object and not a 403 exception. If it works within your browser, is the computer that your using the browser on the same as what you are trying to run the server on? That URL works perfectly fine on my computers (laptop and servers).

Also very important:
Does the Prison plugin still work? Or does it kill the server or just the prison plugin?

I'm trying to dig a little deeper on this issue, and one cause sounds like the requests are going through to the destination server, but its the server that is responding with a 403 instead of the data payload. One person identified that there was a lack of a reverse DNS setup for the IP address that they were using to access that URL. It's like its a spam or a DDOS degree of protection that they have on their server that is causing the 403. They said they had to setup a reverse dns entry for their server and they had to complete a captcha to reenable their IP address.

If this is the case, then the issue is with your IP and the destination server (http://api.spiget.org/v2/resources/1223?ut=1574275780699) is blocking it. If this is the case, then there is nothing we can do other than to ensure such failures do not kill the server. But if you review the stack trace, it does appear as if the exception is being ran asynchronously out of a general thread pool that is not under the plugin's control. Hence we may not be able to trap it. If we cannot trap it directly, I'll have to write my own code in order to keep the SpiGet plugin from killing the server.

I'm trying to identify what the cause of this 403 is and how to fix it. I'll post an update when I get some more answers. But in the mean time, if you can provide a little more information that would help greatly too!

Thanks greatly for your help and patience in getting this resolved!
Blue

Word from the plugin creator is that it should be https and not http. I'm not sure why it would be degrading to http on your server? He suggested that the reason it is getting a 403 may be due to cloudflare might be blocking it. Not sure why yours would be trying to use http and not https? Do have a valid certificate, or did it expire? If it is still valid, then could it be self-signed?

im_a_waffle,

Figured out why this is failing. There are a few reasons that can contribute to this overall problem that you're seeing.

1. You're running 1.14.4 which is not yet supported. I'll be trying to get the project updated with full 1.14.4 support in the next week or two.

2. You're using v3.1.1 which is obsolete. Yes, it is the only latest version available on the main project, but I will be pushing out an updated version in the next few days. You could possibly try a build artifact from my fork but if you run it with 1.14.4 then it will fail miserably in other ways because libraries that we depend upon forced us to update to their newest release and they dropped support for some of the dependencies that we were expecting. So I'll have to rebuild the libraries from scratch to get full 1.14.4 support.

3. There was a major update in the spiget plugin. The older version is no longer available on their repositories. The current version that is being used, within in my fork, appears to be using https. I can only assume that may be why they eliminated the older library from their repository is due to the failures it was generating when trying to access their more secure API. When I try to access the same resource via the browser and using http, cloudflare injects headers in to the payload which may allow non-https access due to the third party verification that the ray is valid. Yes sometimes cloudflare does require me to authenticate via recaptcha, so not sure if that is having an impact.

So for now let's put this on a hold until the new 1.14.4 support comes out. There is an excellent chance it will be fully resolved by then.

Thanks,
Blue

Fixed in v3.2