+1
with at least 4 people watching the same tv shows at different times, it would be a fantastic feature!
+1
I agree with the multi-user environment, there is nothing worse that missing episodes, and not realizing ...
I hope this will be helpful for you
http://forums.plexapp.com/index.php/topic/69160-2-users-1-server/
Two issues with "require authentication on local networks"
1 Any client that does not support myPlex loses access, eg LG TV client
2 The shared users lose access to watched/unwatched status
+1
+1
Totally agree :)
I'm hoping that that is a good documented API around this, and that use of myPlex isn't a requirement. If so, I would like to ask that Google Plus sign in be an option for integration to the server for authentication for multiple users. Personally, if the server is running locally, there shouldn't ever be a need to authenticate in the cloud, the server should be able to handle this. I know you want more and more people to use myPlex and then the premium features. I'd be fine with the Multi-User support being a myPlex/Plex Pass premium feature, but as long as it was an optional feature, and that sign-in to a local server isn't a requirement.
Without a good documented API, third party clients are going to have a difficult time supporting plex as a connection option.
It’s simple to make multiuser work for a third party client, and yes, myPlex is a requirement.
curl -H “Content-Length: 0” -H “X-Plex-Client-Identifier: my-app” -uxxx:yyy -X POST https://my.plexapp.com/users/sign_in.xml
That nets you a token. Use that token to retrieve servers at /pms/servers.xml?X-Plex-Token=ttt. Use the token when connecting to servers remotely and on the LAN to identify yourself.
Here is our internal documentation on making a client multiuser aware:
- Send the appropriate token to a server even if you’re using a local network connection.
- Send /:/timeline to local and non-owned servers (not /:/progress).
- Allow stream selection on non-owned servers.
- Allow rating media on non-owned servers.
- Allow marking media (un)watched on non-owned servers.
Multiuser support is advertised as multiuser=“1” at the root XML.
Thanks for the response. I'm assuming that all the new API will eventually be documented on the developers wiki pages so that devs don't need to scrounge around the dev forum to find the necessary information?
So I'm assuming that since myPlex is a requirement, that there really is no user management on the server itself. Is there a reason that you are not using a standard authentication mechanism like OAuth to allow access? Any possibility of allowing and using something like Google Plus signin?
-uxxx:yyy is a username and password? for myplex
And what are the available &state= values
And the duration, that seems to be mandatory, is that to calculate the progress? I'd assume you alerady knew that from the rating key.
@kingargyle ~ no plans to support OAuth at this time.
@psycik ~ xxx & yyy are username (or email) and password. Duration is mandatory (can be grabbed from element). The timeline handler doesn't want to do the extra work to get the duration, might be from an (indirect) online video too, e.g. States are {paused, buffering, playing, paused, stopped}.
Thanks élan (btw psycik = davidcole on twitter)
How is the token used in future transactions? Or is the obtained of the token all that is required?
-uxxx:yyy is a username and password? for myplex
Elan this looks like it is just using http basic authentication. Unless an HTTPS connection the user name and password are in plain text and base64 encoded. Shouldn't this be in a JSON or XML payload sent back with the https request. at least that information would be better encrypted. The basic auth only does base64 encoding. So since currently only the upcoming servers are going to have the ability to do SSL. the current myplex connectivity for somebody to sign into isn't encrypted at all, and the username and password could theoretically be intercepted by a man in the middle.
So I would guess that in the future all myPlex communication would need to use HTTPS and would hope something more than base64 encoding is used. Guess why I would prefer a standard signin solution like OAuth2 or being abile to authenticate with Google Plus or another trusted source for the user to sign into my plex.
For local communication HTTP should be good enough, but external especially with myPlex communication back to the server, it should be all done with HTTPs.
Elan this looks like it is just using http basic authentication. Unless an HTTPS connection the user name and password are in plain text and base64 encoded. Shouldn't this be in a JSON or XML payload sent back with the https request. at least that information would be better encrypted. The basic auth only does base64 encoding. So since currently only the upcoming servers are going to have the ability to do SSL. the current myplex connectivity for somebody to sign into isn't encrypted at all, and the username and password could theoretically be intercepted by a man in the middle.
Huh? The basic auth is ONLY for talking to myPlex, which has supported HTTPS since day 1. You should always use HTTPS when communicating with myPlex.
So I would guess that in the future all myPlex communication would need to use HTTPS and would hope something more than base64 encoding is used. Guess why I would prefer a standard signin solution like OAuth2 or being abile to authenticate with Google Plus or another trusted source for the user to sign into my plex.
All communication with myPlex DOES use HTTPS and has from the start.
For local communication HTTP should be good enough, but external especially with myPlex communication back to the server, it should be all done with HTTPs.
We just added HTTPS to the media server so that all communication between clients and servers is encrypted. Communication between clients and myPlex (and servers and myPlex) has ALWAYS been encrypted.
@kingargyle ~ no plans to support OAuth at this time.
@psycik ~ xxx & yyy are username (or email) and password. Duration is mandatory (can be grabbed from element). The timeline handler doesn't want to do the extra work to get the duration, might be from an (indirect) online video too, e.g. States are {paused, buffering, playing, paused, stopped}.
So I'm trying to do this in dot net.
System.Net.WebClient client = new System.Net.WebClient();
client.Encoding = Encoding.UTF8;
client.Headers.Add("X-Plex-Client-Identifier", "my-app");
string data = "-uxxx:yyy";
string temp= client.UploadString("https://my.plexapp.com/users/sign_in.xml", data);
Is this correct? The -uxxx:yyy seems wrong to me, it's not a name value/JSON like the other calls for progress etc.
The -uXXX:YYY is HTTP Basic Auth. dot NET should have a way of doing that in WebClient.
The -uXXX:YYY is HTTP Basic Auth. dot NET should have a way of doing that in WebClient.
Ahh and here was me thinking it had to be a parameter of the post request.
Does anyone know how long myPlex tokens are good for? Or once I have a token am I set for life? Right now I have my server set to grab the current token every 24 hours but I'm wondering if that's even necessary.
