Stats failed to fetch

[Californ1a]

If your plex server is only set up to be used in your internal network, or for any other reason you have "Not available outside your network" in the Remote Access settings, then the external [ip/id].plex.direct:20307/library/sections/?X-Plex-Token= url the stats page tries to fetch from will fail and the stats page will just be permanently darkened/loading.

Could there be an option to use an internal address like 127.0.0.1:32400/library/sections/, 10.0.0.75:32400/library/sections/, or 192.168.0.75:32400/library/sections/ to fetch the stats?

[Balthier]

From the face of it, seems possible - I'll take a look this week

[Balthier]

So, doing some testing with Remote Access disabled, and I'm still able to get stats using the plex.direct connection. I didn't disable my FW rules, just the setting in Plex itself...

Could you turn on the Debug settings in the EnhancedPlex settings, and then provide me with the console output from the stats page? - Just want to double check that something else isn't going on too

Either way, the idea of connecting locally if possible, is probably a better/quicker option than going through the plex.direct proxy, so I am going to look at getting that sorted when I can.

[Californ1a]

Same also happens within plex on show pages as well, anything using the getXML function when plex.direct is unaccessible: (btw, Show Tokens toggled off doesn't hide the token in the getPlexToken debug log)

[Balthier]

Ok, I'll see if I can get an installation configured for this specific issue, to help me replicate/test

I've created a second issue for the getPlexToken

[Californ1a]

There's a few potential automated solutions that might work without needing the user to config a separate option, like keep an entry in storage for what host address to use for fetching, and if it's empty, check document.location.host on plex pages before fetching to see if it's localhost or a local ip, then try fetching from there instead, and if it works, save that address so it can also be used from the stats page. If it fails then fallback to plex.direct. An override option to manually config the address would be nice to have though, but probably better for less advanced users if it can attempt to automatically find the right address.

[Balthier]

Yeah, there is already the information that is pulled fairly early in the extension, it just isn't stored at the minute, since the uri/plex.direct link is already presented in the correct format - Should be able to build the local link with the additional info in the xml

[Balthier]

Ah. I remember why I moved away from this originally - You can't make HTTPS calls to the direct IP addresses, due to the SSL certificate.

It works via HTTP, when using the option "Secure Connections" set to "Preferred", but will obviously error on "Required"

The easiest workaround is going directly to the https://IP:PORT, and manually accepting the certificate warning

It's been a few years since I last looked in to this, so I'll do some digging to see if anything has changed since I last investigated

[Californ1a]

Insecure is probably better than not working at all (assuming secure connections is set to preferred), especially if it's localhost/127.0.0.1 and not actually making any external request. If it's from another device on the same network (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) then it would probably be better to be https since there is actual network traffic happening, but maybe that could be optional depending on each user's particular network config - if they specifically enter an override address with http or https.

Edit: This might actually be less of an issue with using plex.direct itself and moreso with creating/finding the correct plex.direct url. Tautulli for example, autodetects internal addresses when secure connections are enabled in their settings: I'm not sure if they're only able to autodetect the correct url since it's an app running on the machine rather than a browser extension, but it seems like there is a way to go via plex.direct for secure internal connections rather than using the public ip version.

[Balthier]

Made some changes to the URI selection process:

Local (Direct, HTTPS) -> Local (Plex Proxy) -> Local (Direct, HTTP)

I still haven't been able to reproduce the issue, but hopefully, this new selection process covers a variety of scenarios.