[Question] Avoid new authorized device for every request

[cosimochellini]

Hi, I'm using as documentation says the plex api credentials for the login and this flow correctly works, but every time I use this endpoint to query the plex library on the Authorized Devices's list in the plex app a new device is added to the list, so now i have this situation.

Can i do something to prevent this side effect ? If you need more detailed info/ spec of the stack I'm using I'm happy to tell you 😃

[phillipj]

That surely looks unfortunate! Can't remember that happened to me before, but it's been a while since I used plex for myself though.

[cosimochellini]

could it be that it is hosted in a serverless environment? but it seems strange to me anyway 😕

[tepsukka]

I'm late but for anyone having the same issue...

Maybe because you're not passing an identifier in the options, so it's generating a new UUIDv4 every time you initialize the API, which makes Plex think that the requests are coming from different apps?

Relevant part from the docs:

• options: override additional PlexHome options (optional, but recommended for PlexHome)
  • identifier: A unique client identifier. Default is a generated uuid v4. Note: you should really provide this rather than let it get generated. Every time your app runs, a new "device" will get registered on your Plex account, which can lead to poor performance once hundreds or thousands of them get created. Trust me!

[phillipj]

@tepsukka ohmy, great catch!

Sorry I didn't connect those dots earlier.

Seeing that .identifier documentation now, makes me question the benefit of this package trying to be "helpful" by generating an UUID when no explicit identifier is provided. Wouldn't it be better to enforce the using code to provide a sensible identifier? 🤔

[cosimochellini]

thanks for the solution, for the moment I had used as a temporary solution to simply pass token and hostname, also in this case the connection works without duplicating the connected devices

import { config } from 'dotenv';
import * as PlexAPI from 'plex-api';

config();

const token: string = process.env.TOKEN || 'token';
const hostname: string = process.env.HOSTNAME || 'hostname';

const client = new PlexAPI({ hostname, token });

export { client };

Surely this is THE solution, thx again @tepsukka

[tepsukka]

@cosimochellini That's great that you found a solution that worked for you.

@phillipj Moving the identifier management to the library user sounds like a reasonable enough change to me. Especially since I don't see any way this library could actually persist the identifier it generates for later re-use.

Although, I would guess it would be a breaking change if the identifier is required by the Plex API. Code or apps that are relying on the identifier generation would break if the Plex API requires it. Hard to find good documentation on that matter, easy enough to test though. It would also have the added benefit of getting rid of a dependency too, assuming the uuid library is not used elsewhere (doesn't seem like it).

Reading through https://forums.plex.tv/t/authenticating-with-plex/609370 especially this part:

Generate a Client Identifier The Client Identifier identifies the specific instance of your app. A random string or UUID is sufficient here. There are no hard requirements for Client Identifier length or format, but once one is generated the client should store and re-use this identifier for subsequent requests.

It does seem like Plex expects an identifier to be present, but doesn't really set any limits on what the identifier should be.

[phillipj]

Moving the identifier management to the library user sounds like a reasonable enough change to me. Especially since I don't see any way this library could actually persist the identifier it generates for later re-use.

Thanks for confirming @tepsukka.

Although, I would guess it would be a breaking change if the identifier is required by the Plex API. Code or apps that are relying on the identifier generation would break if the Plex API requires it.

Yepps, would for sure be a major version bump.

Sounds like something we better validate upon instantiation and throw a descriptive error if not the identifier is present.