Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mwillems]

So I'm trying to figure out how the "Authentication" and "Read-Only" options under media network work together.  What I'm trying to achieve is a situation where certain clients can connect to the server using authentication with a username and password so they can make tag changes, while all other clients can connect read-only without a password. 

In the menu options you can check the authentication box, and then also specify read-only access without a password.  So far so good, that seems like it should permit both kinds of access.  But there are some problems.

First, with authentication checked and read-only set to "without password", all my clients immediately just connect read only and don't prompt for a password.  That's fine as far it goes; that's actually the behavior I want for remotes like Panel or Gizmo, for example.  But in the full-fat desktop MC clients there's no obvious way to "force" an authenticated/read-write connection, they just connect read-only silently and automatically.  It feels like there should be a button or an option under the "library options" menu that let's you specify how you want the client to connect, but there doesn't seem to be one.

So as an experiment, I tried 1) disabling read-only authentication on the server so only authenticated connections are permitted and then 2) disconnecting and reconnecting my desktop clients.  As expected the user interface prompted for a username and password, and I entered the username and password and checked the "remember" box to save the credentials and all the desktop clients I tested made an authenticated/read-write connection with no problem.  Then I turned read-only access back on to see if the clients would "remember" that they have credentials for an authenticated connection to the server, or if they'd fall back to read-only.

Here's where it gets weird.  After turning read-only access back on, I disconnected and reconnected my clients.   However, while some of the desktop clients established an authenticated/read-write connection, others established a read-only connection, despite the fact that I'd just gone through the same steps on all of them!  I tried repeating the experiment a few times and it worked the same way each time; some clients connected read only and some connected read-write (it was the same clients in each category each time).  I haven't figured out what causes some clients to go one way and some clients another, which is less than ideal.

It seems like it's at least possible to get the behavior I want with existing functionality, I just can't do it deterministically.  If I'm missing something obvious let me know, but otherwise I think some kind of client-side setting for whether the client should try to make an authenticated or read-only connection would be a nice feature to have.

[RoderickGI]

This has been discussed directly and indirectly several times. You haven't missed anything obvious. You have described the issue very well.

Although some Clients connecting using Read/Write Authentication after you turn on Read-only Authentication is a new twist. Previously everyone has reported Clients can only connect with Read-only Authentication once it is turned on, if there is no password set up for that. Maybe there is some dependency on whether the MC Server has been restarted, or the MC Server PC or MC Client PC has been restarted. Perhaps some caching somewhere.

The alternative of not saving passwords on any Clients, so that users have to enter a Username and Password every time they start a MC Client, even for Read-only Clients, is not very palatable for anyone. I'm not even sure if that works. Besides, once you have given the Client the Username and Password there doesn't appear to be any way to clear the information from the Client. There is a "Reset saved internet passwords" setting, but I don't think that clears Client Usernames and Passwords. The only way I have been able to make the Client ask for a Username and Password again is to change them on the MC Server.

I suspect that only one Username and Password combination is stored on the Client, and that Read-only Authentication with no Password is tried first. But if the Username is different for Read/Write and Read-only Authentication, then the user should at least be asked for a Username when starting the Client, to check the Password against. I assume that you are using or have tried using different Usernames for Read/Write and Read-only Authentication?

I'm sort of having the opposite problem at the moment. My Client is asking for a Username and Password fairly regularly, but not always, and I only have Read/Write Authentication turned on. That would imply that my Client is forgetting the Username and Password that has been saved, which may explain why some of your Clients connect with Read-only in your experiment; those Clients may be forgetting the Read/Write Username and Password, and so falling back to Read-only Authentication. But how does the Client know which Username to use? Maybe it doesn't care about the Username if the Password is blank.

Anyway, some way to allow each Client to connect either with Read/Write or Read-only Authentication, on start of the Client based on user inputs, would be good. That goes a bit beyond your request to provide a Client side setting, which would restrict the Client to just one Authentication method. But for other people who have struggled with the issue, it would be better. Some of them wanted to normally start the Client in Read-only Authentication mode, but sometimes want to be able to start in Read/Write Authentication mode to do some maintenance.

[mwillems]

Anyway, some way to allow each Client to connect either with Read/Write or Read-only Authentication, on start of the Client based on user inputs, would be good. That goes a bit beyond your request to provide a Client side setting, which would restrict the Client to just one Authentication method. But for other people who have struggled with the issue, it would be better. Some of them wanted to normally start the Client in Read-only Authentication mode, but sometimes want to be able to start in Read/Write Authentication mode to do some maintenance.

Really what I want a setting in desktop MC's library manager that says "connect to server using:" and then have a toggle that can be switched between "authentication (if possible)" or "read only".  If you toggled the setting, the client would then disconnect and reconnect in the specified configuration.  As long as the setting is remembered, a setting like that would solve both my case and the other cases you describe wouldn't it?  One could leave it set how one pleases, and then toggle it whenever you want.

The alternative of not saving passwords on any Clients, so that users have to enter a Username and Password every time they start a MC Client, even for Read-only Clients, is not very palatable for anyone. I'm not even sure if that works.

I definitely don't want that as universal behavior, especially not for remotes.  What I'm specifically trying to achieve is to keep the ability to use panel without a password prompt, but to be able to configure some desktop clients to send tag info back.  It seems like  there could be a config option for this that wouldn't break anyone's existing workflows, but would give a little extra flexibility.

I suspect that only one Username and Password combination is stored on the Client, and that Read-only Authentication with no Password is tried first. But if the Username is different for Read/Write and Read-only Authentication, then the user should at least be asked for a Username when starting the Client, to check the Password against. I assume that you are using or have tried using different Usernames for Read/Write and Read-only Authentication?

I actually haven't tried using different credentials for the two options because that wouldn't actually work in my use case.  I need the read only clients to be able to connect without a password because my daughter uses panel now with some regularity and having to enter a password is not really doable for the kiddo, and saving passwords in a browser still requires her to navigate and understand a password prompt which I'm trying to avoid. 

When I have some more time later on, I'll give it a try just as an experiment and see what comes from it.

[RoderickGI]

Yep, I agree with all that.

Without wanting to derail your request, it would seem logical to tie Authentication to the MC User, and then have a Client remember the User it should log into, and the credentials. Others have asked for that, so that the Client doesn't just get the MC User that is logged in on the MC Server. I don't use the MC User functionality but understand it is quite limited. Add a method to toggle between MC Users and that should just about achieve your goals.

[mwillems]

Just a gentle bump here; could any of the JRiver folks weigh in on whether they would consider creating a client side option to address this issue?

A quick summary: Currently when a server has both authentication enabled and read-only access for everyone enabled, there's no way to select which one you want on the client.  That means that clients with saved authentication credentials seem to "choose" one of the two at random, and clients without saved credentials can only connect read-only.  I'm proposing a setting in desktop MC (probably in library manager) that says "connect to server using:" and then have a toggle that can be switched between "authentication (if possible)" or "read only".  If you toggled the setting, the client would then disconnect and reconnect in the specified configuration.  What I want to avoid is having a password prompt for all connections because that would make using remotes like Panel much less convenient and defeat the purpose of passwordless read-only access.

It seems a bit too complex for a "too easy" thread or I'd post it over there.

[bob]

Just a gentle bump here; could any of the JRiver folks weigh in on whether they would consider creating a client side option to address this issue?

A quick summary: Currently when a server has both authentication enabled and read-only access for everyone enabled, there's no way to select which one you want on the client.  That means that clients with saved authentication credentials seem to "choose" one of the two at random, and clients without saved credentials can only connect read-only.  I'm proposing a setting in desktop MC (probably in library manager) that says "connect to server using:" and then have a toggle that can be switched between "authentication (if possible)" or "read only".  If you toggled the setting, the client would then disconnect and reconnect in the specified configuration.  What I want to avoid is having a password prompt for all connections because that would make using remotes like Panel much less convenient and defeat the purpose of passwordless read-only access.

It seems a bit too complex for a "too easy" thread or I'd post it over there.

How about a client side media network option like "Read-Write connections only" which when enabled will only try read-write authorization?

[mwillems]

How about a client side media network option like "Read-Write connections only" which when enabled will only try read-write authorization?

So I think that would solve part of the problem, certainly for clients that will always have the same role.  You could just not provide credentials on clients you want to be read-only and check the box on clients you want to be read-write.  It's been a few years, but the other half of the issue was that if both read-write and read-only were enabled on the server, a client that had ever had saved credentials would just pick read-only or read-write at random with no way for the user to pick which one.  Forcing read-write would work if that's what you want permanently, but what if you want to connect that client read-only in the future?  There's no user-accessible way to remove the credentials and there's no way to force it to pick read-only once you've entered the credentials.

If that sounds kind of contrived, let me explain the use case.  I have an HTPC in the living room that's a client to my server.  Generally, I want it to be read-only (I don't want the kid or friends accidentally changing anything), but sometimes I want to be able to do tag maintenance there instead of logging into the headless server.  Right now there's no way to do that because if I enter the credentials on the client, it will sometimes pick read-write and sometimes read-only, but it's not deterministic and I can't choose which one on the client side.  Your toggle would let me force it to read-write, but there would be no way to guarantee that I'd get back to read-only short of clearing the credentials, which currently requires digging in to the library files and editing manually (I think?).

So your option would solve part of the issue for sure, but what I'd really like is a way to deterministically make a client connect read-only *or* read-write when the server supports both.  Does that make sense? 

[zybex]

Agreed, this has also happened to me and I had to clear stored credentials from the registry.

Best would be an explicit checkbox to select "[ x ] Connect in read-only mode":
- If checked, try to connect using saved GUEST credentials; if that fails try a blank password; if that also fails, ask the user for username/pass (which MUST match the guest user/pass)
- If unchecked, do the same logic but for the admin user/pass
- If connection fails with a saved user/pass, ALWAYS ask the user for new credentials; do not fallback to read-only mode if the checkbox is clear.

This means MC would save/cache both sets of credentials, and use one or the other according to the checkbox.