Essentials icon indicating copy to clipboard operation
Essentials copied to clipboard
verified publisher icon EssentialsX

The EssentialsXSpawn API provides no means of determining where a player will respawn.

Open gibsonpil opened this issue 1 year ago • 3 comments

Feature description

I propose that the logic used in EssentialsSpawnPlayerListener is moved to a method called getUserSpawn in the SpawnStorage class. Additionally, a method to access that method should be added to EssentialsSpawn and IEssentialsSpawn, similarly to what was done for getSpawn and setSpawn.

How the feature is useful

As of now, developers who want to work out where EssentialsXSpawn will respawn players are forced to replicate the logic in EssentialsSpawnPlayerListener. Having such a requirement makes EssentialsXSpawn harder to support for plugin developers and could result in compatibility issues should the logic EssentialsXSpawn uses ever changes.

I'm willing to implement this and submit it via pull request should this feature be accepted.

Edits

  • I took a closer look at the Essentials source code and made a few modifications to my proposal. I think that using an Essentials User instead of a Bukkit Player would probably make more sense. Additionally, moving the logic for determining where a player will spawn to SpawnStorage would probably be more sensible than putting it in EssentialsSpawn.

gibsonpil avatar Jun 06 '24 19:06 gibsonpil

Do you see any results if you enable Show Unsupported option in the main menu?

oscfdezdz avatar Jun 15 '24 20:06 oscfdezdz

I'm experiencing the same issue on Fedora 40 where not only do searches yield a No Results Found message, but checking the details of installed extensions also shows An Error Occured. I tried enabling Show Unsupported but it didn't change anything. Neither did extension manager output any logs related to the issue. I've also reinstalled extension manager deleting all data from the ~/.var folder in the process but it still did not fix the issue.

cameronaw13 avatar Jun 30 '24 21:06 cameronaw13

Do you, by any chance, use a proxy? It seems to be a network problem and we are still having issues with it, see #315.

oscfdezdz avatar Jun 30 '24 21:06 oscfdezdz

Yeah I just realized that I should've checked extensions.gnome.org. I'm not running behind a proxy, its just that the extension website is down. Unless op had a different problem, this issue is out of scope.

cameronaw13 avatar Jun 30 '24 21:06 cameronaw13

Same for me, website is working, app not (no results found)

ppogorze avatar Jul 05 '24 08:07 ppogorze

same happens for me regardless of network configuration

b1ek avatar Jul 23 '24 04:07 b1ek

wasn't sure at first what cameronaw13 meant by "It's just that the extension website is down." The website extensions.gnome.org is down and that is causing the issue with No Results Found on the app. makes sense. image

GogiBenny avatar Jul 24 '24 23:07 GogiBenny

The app's GUI should probably show a more accurate error when it receives an unexpected HTTP response error code, to indicate that the server is down?

nekohayo avatar Jul 25 '24 11:07 nekohayo

I run on Fedora and the only issue that causes this is turning on automatic proxy in network settings (System wide, not browser).

HieuNGN avatar Aug 15 '24 13:08 HieuNGN

Same here on a Newly-installed Ubuntu 24.04.01, whether with a proxy or not.

UserID0001 avatar Oct 20 '24 09:10 UserID0001

extensions.gnome.org is currently down.

oscfdezdz avatar Oct 20 '24 09:10 oscfdezdz

extensions.gnome.org seems to be up and running, but I still see "No Results Found" in the Browse tab. Any steps I can take to help debug this?

If that helps, this is what I see in the console when trying to run a search:

(extension-manager:3): GLib-Net-WARNING **: 15:58:53.235: Failed to load TLS database: System trust contains zero trusted certificates; please investigate your GnuTLS configuration

guillaumedavidphd avatar Oct 24 '24 22:10 guillaumedavidphd

I'm still running into this issue on Fedora 41 Silverblue after a couple weeks after the upgrade. It worked before the upgrade (on Fedora 40). I do have "Show Unsuppoted" checked. I've tried uninstalling and reinstalling the flatpak (from the flathub repo), changing networks, rebooting, etc. Nothing seems to work. I've confirmed the extensions website (https://extensions.gnome.org/) has been up. Based on the error message posted above, my guess it's a cert signing issue.

color00 avatar Nov 09 '24 12:11 color00

Can you try if you can reproduce it with the latest development build? It's in the artifacts section of the latest workflow run: https://github.com/mjakeman/extension-manager/actions/runs/11706464311

oscfdezdz avatar Nov 11 '24 18:11 oscfdezdz

i had this problem on fedora 41 but i guess it's fixed now, i had to reinstall the app for it to work tho(for some reason) Now it's working fine to search any extension.

JonasAlv avatar Dec 01 '24 15:12 JonasAlv

@guillaumedavidphd @color00 is the cert signing issue present in version 0.6? It was released about 3 days ago.

oscfdezdz avatar Dec 08 '24 22:12 oscfdezdz

@oscfdezdz Now seeing a connection error:

Screenshot from 2024-12-09 14-23-38

guillaumedavidphd avatar Dec 09 '24 23:12 guillaumedavidphd

Same. "Connection Error"

(extension-manager:3): GLib-Net-WARNING **: 15:42:38.358: Failed to load TLS database: System trust contains zero trusted certificates; please investigate your GnuTLS configuration

aph11 avatar Dec 25 '24 14:12 aph11

@oscfdezdz Now seeing a connection error:

Screenshot from 2024-12-09 14-23-38

The error message has changed a bit to "Unacceptable TLS certificate" instead of "Check your network status and try again".

guillaumedavidphd avatar Mar 26 '25 15:03 guillaumedavidphd

The error message has changed a bit to "Unacceptable TLS certificate" instead of "Check your network status and try again".

Looking for that error message specifically it seems that it is a common error, in most cases I see it should be enough to reinstall the ca-certificates package.

See https://itsfoss.com/unacceptable-tls-certificate-error-linux/, for example, although you can find many more by searching for that specific error message.

Although I find it strange that it is only an issue with Extension Manager, there should be more applications experiencing the same problem with that error message or similar.

oscfdezdz avatar Mar 28 '25 22:03 oscfdezdz

Looking for that error message specifically it seems that it is a common error, in most cases I see it should be enough to reinstall the ca-certificates package.

Sure, I agree it should be enough. The problem is that re-installing ca-certificates does not solve the issue. I also don't have any certificate issues with any other applications running on my machine.

guillaumedavidphd avatar Mar 28 '25 23:03 guillaumedavidphd

Try running curl -Iv https://extensions.gnome.org in a terminal, it will show if there is a problem with any certificate connecting to the URL.

If it mentions that the certificate has expired, you can check which particular certificate it is with: openssl s_client -connect extensions.gnome.org:443 -servername gnome.org.

oscfdezdz avatar Apr 26 '25 07:04 oscfdezdz

Thanks for the suggestion, @oscfdezdz. I tried running curl -Iv https://extensions.gnome.org and it completed successfully. I also ran it from the flatpak by first issuing flatpak run --command=bash com.mattjakeman.ExtensionManager and then curl -Iv https://extensions.gnome.org. It completed successfully as well.

Anything else I can try?

guillaumedavidphd avatar Apr 26 '25 16:04 guillaumedavidphd

You have probably already tried it but if not try reinstalling, uninstalling with flatpak uninstall --delete-data com.mattjakeman.ExtensionManager.

oscfdezdz avatar May 23 '25 11:05 oscfdezdz

Yes - no dice.

guillaumedavidphd avatar May 23 '25 18:05 guillaumedavidphd

~I'm experiencing the same TLS cert issue currently:~

** (extension-manager:3): CRITICAL **: 17:35:52.165: GDBus.Error:org.gnome.Shell.Extensions.Error.InfoDownloadFailed: Unacceptable TLS certificate

Update: my apologies, in my case it wasn't an Extension Manager issue, but a misconfiguration that was 100% my own doing.

I'd recommend others to test this as well by running gio cat https://extensions.gnome.org and validating if the command results in the same TLS error message. If it does, the issue is not with the Extension Manager Flatpak, but with Gnome.

crahan avatar Jun 04 '25 15:06 crahan

I finally resolved the issue. I happen to have Homebrew installed on my system. Homebrew ships with some TLS related executables, such as trust. These executables override the system's by having higher priority in PATH. I started suspecting this after having other TLS related issues with other Flatpaks.

A quick test for this is removing Homebrew's lines in .bashrc or .profile, logging out and back in, and trying Extension Manager again. In my case, the TLS error was gone after this change.

I'd like to keep using Homebrew, though. I'm not sure how to configure it so that it does not interfere with Flatpaks.

guillaumedavidphd avatar Aug 28 '25 22:08 guillaumedavidphd

I had the same issue. I was using a network proxy. Once I disabled and checked. It was working perfectly for me.

unstopablejay avatar Oct 08 '25 07:10 unstopablejay

Having the same issue on Bazzite (and it has brew installed):

Image 
$ gio cat https://extensions.gnome.org        
gio: https://extensions.gnome.org: Inakzeptables TLS-Zertifikat

cURL on the host also has the error though:

$ curl -Iv https://extensions.gnome.org
* Host extensions.gnome.org:443 was resolved.
* IPv6: (none)
* IPv4: 3.223.219.129, 98.94.114.110
*   Trying 3.223.219.129:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.execute-api.us-east-1.amazonaws.com
*  start date: Mar 22 00:00:00 2025 GMT
*  expire date: Apr 19 23:59:59 2026 GMT
*  subjectAltName does not match hostname extensions.gnome.org
* SSL: no alternative certificate subject name matches target hostname 'extensions.gnome.org'
* closing connection #0
curl: (60) SSL: no alternative certificate subject name matches target hostname 'extensions.gnome.org'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.

Inside the flatpak it seems to timeout first, but then works

$ flatpak run --command=bash com.mattjakeman.ExtensionManager
…
$ curl -Iv https://extensions.gnome.org 
* IPv4: 98.94.114.110, 3.223.219.129
*   Trying 98.94.114.110:443...
* connect to 98.94.114.110 port 443 from 192.168.1.174 port 45050 failed: Connection timed out
*   Trying 3.223.219.129:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.execute-api.us-east-1.amazonaws.com
*  start date: Mar 22 00:00:00 2025 GMT
*  expire date: Apr 19 23:59:59 2026 GMT
*  subjectAltName does not match hostname extensions.gnome.org
* SSL: no alternative certificate subject name matches target hostname 'extensions.gnome.org'
* closing connection #0
curl: (60) SSL: no alternative certificate subject name matches target hostname 'extensions.gnome.org'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.

Inside the Firefox flatpak so just in/with a browser it is accessible though (that likely ships with it's own TLS stuff though and I also have DNS over HTTPS enabled).

GNOME Web also fails:

Image

System

$ flatpak info com.mattjakeman.ExtensionManager

Extension Manager - Install GNOME Extensions

          ID: com.mattjakeman.ExtensionManager
         Ref: app/com.mattjakeman.ExtensionManager/x86_64/stable
        Arch: x86_64
      Branch: stable
     Version: 0.6.5
     License: GPL-3.0-or-later
      Origin: flathub
  Collection: org.flathub.Stable
Installation: system
   Installed: 2.4?MB
     Runtime: org.gnome.Platform/x86_64/49
         Sdk: org.gnome.Sdk/x86_64/49

      Commit: cc7f0c3f400aaad37c61f042a4a2816d2c1330a49c005b4710d1134fd79287f3
      Parent: 6578e2e39cc43379ef45983a3aad4c8a2bd21a29a5f13fee238d58ea988a9a82
     Subject: Merge pull request #28 from flathub/v0.6.5 (6336c8a59575)
        Date: 2025-10-01 16:58:26 +0000
$ rpm-ostree status -b
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
BootedDeployment:
* ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:stable
                   Digest: sha256:1527efbb34402c8c019a6c0dcd404845c0432590b52aaa92e8ce4fc209b17a52
                  Version: 42.20251029.1 (2025-10-29T04:40:08Z)
      RemovedBasePackages: code 1.105.1-1760482588.el8
          LayeredPackages: bsdtar …

rugk avatar Nov 12 '25 17:11 rugk

Okay I can confirm it's a homebrew issues (thx a lot @unstopablejay would have never come up with that!), because the simple test is to reset PATH and then run cURL (with an absolute path) and it works flawlessly then:

$ PATH="" /usr/sbin/curl -Iv https://extensions.gnome.org
* Host extensions.gnome.org:443 was resolved.
* IPv6: (none)
* IPv4: 34.224.225.95, 3.213.66.110
*   Trying 34.224.225.95:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / RSASSA-PSS
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=extensions.gnome.org
*  start date: Oct 13 06:10:00 2025 GMT
*  expire date: Jan 11 06:09:59 2026 GMT
*  subjectAltName: host "extensions.gnome.org" matched cert's "extensions.gnome.org"
*  issuer: C=US; O=Let's Encrypt; CN=R13
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* Connected to extensions.gnome.org (34.224.225.95) port 443
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: extensions.gnome.org
> User-Agent: curl/8.11.1
> Accept: */*
> 
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< server: nginx
server: nginx
< date: Wed, 12 Nov 2025 17:49:40 GMT
date: Wed, 12 Nov 2025 17:49:40 GMT
< content-type: text/html; charset=utf-8
content-type: text/html; charset=utf-8
< content-length: 13821
content-length: 13821
< strict-transport-security: max-age=14400; includeSubDomains
strict-transport-security: max-age=14400; includeSubDomains
< x-content-type-options: nosniff
x-content-type-options: nosniff
< referrer-policy: same-origin
referrer-policy: same-origin
< cross-origin-opener-policy: same-origin
cross-origin-opener-policy: same-origin
< x-frame-options: DENY
x-frame-options: DENY
< vary: Cookie, Accept-Language, origin
vary: Cookie, Accept-Language, origin
< content-language: en
content-language: en
< set-cookie: csrftoken=j4E0lcebfHb8OGADiwp9mAXDjc7hqD7V; expires=Wed, 11 Nov 2026 17:49:40 GMT; Max-Age=31449600; Path=/; SameSite=Lax; Secure
set-cookie: csrftoken=j4E0lcebfHb8OGADiwp9mAXDjc7hqD7V; expires=Wed, 11 Nov 2026 17:49:40 GMT; Max-Age=31449600; Path=/; SameSite=Lax; Secure
< x-content-type-options: nosniff
x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
x-frame-options: SAMEORIGIN
< 

* Connection #0 to host extensions.gnome.org left intact

Also reported this to the distro I am using aka UBlue/Bazzite as they ship with brew: https://github.com/ublue-os/bazzite/issues/3479

rugk avatar Nov 12 '25 18:11 rugk