Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Store a Room Operator password #216

Closed
jimmydorry opened this issue Feb 1, 2019 · 16 comments
Closed

Feature Request: Store a Room Operator password #216

jimmydorry opened this issue Feb 1, 2019 · 16 comments

Comments

@jimmydorry
Copy link

@jimmydorry jimmydorry commented Feb 1, 2019

It would be nice to be able to store a Server Operator password and automatically authenticate on SyncPlay start. It's a bit of a hassle to store it elsewhere, and manually copy+paste to authenticate each time you join a managed room.

The stored password would correspond with the default room you have saved in your client configuration.

For people that have the OP password, and want to join the channel as a non-op, they could just restart syncplay and clear their saved password in the configuration before re-joining the server.

The lack of this kind of functionality is only a small hassle in an otherwise great user experience.

@Et0h
Copy link
Contributor

@Et0h Et0h commented Feb 1, 2019

I think some way of storing room password would be really helpful for people who use managed room (what % of Syncplay users is that? Not sure).

The question of implementation is perhaps a tricky one. I am not sure that having it as part of the default room is the best way to do it because I can imagine circumstances where people are involved in more than one room. However, , if we start going into a whole password manager then it might be more useful if it were a broader 'favourites' facility to make it easier for users to go back to their favourite rooms. This sounds useful and less hacky, but would be more time consuming to develop especially in terms of the correct UI to make it not clutter things up.

What are people's thoughts on this? I don't use managed rooms feature, so getting feedback from people who do would be really helpful.

@jimmydorry
Copy link
Author

@jimmydorry jimmydorry commented Feb 1, 2019

I use a managed room almost every day, with 3-12 people participating (as non-operators) in each session. As you said, the less hacky system of favourites will be more cumbersome to implement, but a functionally better solution.

I'm in support of any improvement in this area.

@Dimonchyk777
Copy link

@Dimonchyk777 Dimonchyk777 commented Feb 1, 2019

I agree with jimmydorry here. I think we should have an option to automatically identify as a room operator. Instead of copying and pasting the password every time.

@Et0h
Copy link
Contributor

@Et0h Et0h commented Feb 1, 2019

I don't really have any 'user stories' for how managed rooms are actually used and how operators behave. To what extent does someone who is sometimes a room operator want to always be identified as such, and to what extend would they want it to be 'on demand'? Do people actually want the ability to 'unidentify' as a room operator half way through a viewing session? If so, why?

@jimmydorry
Copy link
Author

@jimmydorry jimmydorry commented Feb 1, 2019

For the room I manage at least, it's typically a once-off decision at the start of the session. There are two people that can OP in my room. In that room at least, we only want one operator, to make running things simpler.

If one of us wants to de-OP after seeing there is already another OP, it's easy enough to just restart syncplay, but it's never really been an issue in our usage.

For myself at least, I'm almost always the OP, so I always end up authenticating. The other guy ends up authenticating when I'm not part of the session... or he makes his own room.

I hope that helps. I'm sure there is a wide variety of uses of SyncPlay, so I'm not sure if mine is typical.

Et0h added a commit that referenced this issue Aug 18, 2019
@Et0h
Copy link
Contributor

@Et0h Et0h commented Aug 18, 2019

To move things in the right direction I've made it so that when you join a room (from config dialogue or within Syncplay) you can specify the room password and it will auto-authenticate. For example, if the room is +Foobar:C4F2F5B70383 and the operator password is AC-189-667 then you can join using +Foobar:C4F2F5B70383:AC-189-667 and it will auto-authenticate. This will be in Syncplay 1.6.5 and you can test it via: https://bintray.com/syncplay/Syncplay/Syncplay/v1.6.5#files

@jimmydorry
Copy link
Author

@jimmydorry jimmydorry commented Aug 18, 2019

There seems to be a character limit in the room joining dialogue box that truncates the password.

Making a test room with the same character length as the room that our server primarily uses:

room: +testtesttests:676358258578
pass: AZ-193-172

the total room name gets truncated to +testtesttests:676358258578:AZ-193-

Same occurs if you set it in the initial config.

image

@jimmydorry
Copy link
Author

@jimmydorry jimmydorry commented Aug 18, 2019

Trying with a shorter room name, it works perfectly within the client, but doesn't work from the config. +test:E974AACDBEC6:MA-746-375

I'm using SSL, if that changes things. I looked for a a log file but I'm not seeing anything except my config in the %appdata% folder.

albertosottile added a commit to albertosottile/syncplay that referenced this issue Aug 30, 2019
@Kommynct
Copy link

@Kommynct Kommynct commented May 13, 2020

Does anyone know how to make this work from the config now? it has been quite some time and i'm just curious if there's any better way to do this now in 2020.

Et0h added a commit that referenced this issue May 13, 2020
@Et0h
Copy link
Contributor

@Et0h Et0h commented May 14, 2020

@Kommynct @jimmydorry Should now work on v1.6.5 pre-release available from https://bintray.com/syncplay/Syncplay/Syncplay/v1.6.5#files using +test:E974AACDBEC6:MA-746-375 style room name from config.

@jimmydorry
Copy link
Author

@jimmydorry jimmydorry commented May 14, 2020

Thanks, I'll try it out. The issue with the previous commit was truncation. I use the app almost daily, however I'm currently travelling.

Thanks for all of your support and work thus far!

@Et0h
Copy link
Contributor

@Et0h Et0h commented May 16, 2020

I think the issue with the previous version was that it was trying to identify before it got the message from the server saying that managed rooms were supported, and so it cancelled the attempt. Now it just always tries to authenticate if you ask for it to do so.

@jimmydorry
Copy link
Author

@jimmydorry jimmydorry commented May 17, 2020

It works great! Thanks for shipping such a nice QoL feature.

Et0h added a commit that referenced this issue May 17, 2020
@Et0h
Copy link
Contributor

@Et0h Et0h commented May 17, 2020

Glad to hear it works. I've now made it so that when people create a managed room it gives a brief explanation of what they are and on what room name to use to auto-authenticate as the room operator.

Do people have thoughts on whether Syncplay should automatically display a message if their room has more than a certain number of people which asks them to consider using managed rooms? And if such a feature were in place, what do you think the threshold of users should be for it to make that recommendation?

@jimmydorry
Copy link
Author

@jimmydorry jimmydorry commented May 17, 2020

Such a feature would probably drive further adoption of that great feature (managed rooms).

Personally, I feel like any room with more than 5 people without an OP starts to get a bit unwieldy.

@jimmydorry
Copy link
Author

@jimmydorry jimmydorry commented Jun 21, 2020

This feature has been implemented (huge thanks @Et0h ), so I figured it might as well be closed to reduce clutter. I use the new feature almost daily.

@jimmydorry jimmydorry closed this Jun 21, 2020
albertosottile added a commit to albertosottile/syncplay that referenced this issue Sep 30, 2020
albertosottile added a commit to albertosottile/syncplay that referenced this issue Sep 30, 2020
albertosottile added a commit to albertosottile/syncplay that referenced this issue Sep 30, 2020
albertosottile added a commit to albertosottile/syncplay that referenced this issue Sep 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants