Print

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

[stanzani]

I am looking for the best way to share my media library to friends without distributing my personal access key (I do not like people may unadvertently - or not - change / delete / add files)
any idea?

thanks in advance

[rossp]

I have wanted this functionality for a long time so I can share with family and be assured they can't mess up / delete anything.

+1

Ross

[stanzani]

are there issue with copyright? Is this possibly why JRiver do not expose this?
BTW this can be done with ftp adding restrictions to the guest user. I'd love to use JRiver for this, anyway

[mark_h]

are there issue with copyright?

This is a rhetorical question, right?

[Bccc1]

This is a rhetorical question, right?

Why? At least in Germany I'm allowed to share my media (if it's not copy protected) with family and close friends. Just because the option could be abused does not mean that there would be a problem with the copyright on JRiver side.

I also would like an option like that. What I would like even more, would be the option to use the current usermanagement as login credentials. So i would have a user kids and a password that together with the access key would grant the logged in user read only access to a selection of views while hiding the teen/adult stuff.

[stanzani]

This is a rhetorical question, right?

It is
What I am asking looks to me such an obvious feature which I am surprised that the tem did not include in the package so I am tempted to think the obscure forces of capitalism and lobbies are pushing JRiver not to include this

[marko]

Can't you just share without a password? Then you would have read-only.

Maybe, you need a password so that you yourself can make changes if required?
Do you have another PC available?

Our HTPC is a client MC and connects using a password. This helps me as I can make changes from there, or my phone, if needed, but, the girls were a worry... If they get lost, they have a tendancy to 'just start blindly clicking everywhere' until it either breaks, or they get somewhere familiar. This doesn't happen too often now as they are much more familiar than back in the day when I set it up, but, I still needed peace of mind, so, I run media server on the HTPC, without a password, and connected their phones and iPads to that instead of the server.

So, the HTPC gets its library from the server via a password, then in turn, serves it out without a password, thus protecting it from any unintended changes or deletions. If I need to make changes, I either connect directly to the server MC, or do it directly on the HTPC.

If you're talking about sharing across the internet, you could change the port the library is served out from so that it's not default, then consider the chances of someone with a port scanner finding MC at the open port, and knowing what to do with the advertised library data, or finding a way to send MC malformed packets or something to get into your systems? I don't know, but I think the chances of that are pretty low... maybe I'm wrong, don't know, just thinking out loud for you....

It did occur to me that a little tick box on the library server options that would allow a password protected server to allow read only access to requests without a password could be quite useful, but I don't know if JRiver are able to add that.

marko

[mwillems]

Can't you just share without a password? Then you would have read-only.

Maybe, you need a password so that you yourself can make changes if required?
Do you have another PC available?

Our HTPC is a client MC and connects using a password. This helps me as I can make changes from there, or my phone, if needed, but, the girls were a worry... If they get lost, they have a tendancy to 'just start blindly clicking everywhere' until it either breaks, or they get somewhere familiar. This doesn't happen too often now as they are much more familiar than back in the day when I set it up, but, I still needed peace of mind, so, I run media server on the HTPC, without a password, and connected their phones and iPads to that instead of the server.

So, the HTPC gets its library from the server via a password, then in turn, serves it out without a password, thus protecting it from any unintended changes or deletions. If I need to make changes, I either connect directly to the server MC, or do it directly on the HTPC.

That's pretty neat marko, I didn't know it worked like that.

If you're talking about sharing across the internet, you could change the port the library is served out from so that it's not default, then consider the chances of someone with a port scanner finding MC at the open port, and knowing what to do with the advertised library data, or finding a way to send MC malformed packets or something to get into your systems? I don't know, but I think the chances of that are pretty low... maybe I'm wrong, don't know, just thinking out loud for you....

There are increasing risks from port scanners these days.  I set up a web server for the first time in 10 years six months ago, and I learned some new things in the process.  For example, shodan.io is a search engine that crawls ips looking for open ports with services, catalogs the open ports, and then provides a publicly accessible search engine of open ports that anyone can use.  This has the effect of allowing bad actors to avoid exposing their own ip while port scanning and vastly speeding up their search for exposed services. 

My web server gets scanned by shodan a few times a week, and I can search for my ip and find it right there on shodan with all the details of my webserver, etc.  There are several other similar services, so just blocking shodan's ip range doesn't help much.  Researchers and journalists searching on shodan have found unsecured web cameras in public places (or peoples homes), traffic light controllers, media servers, ftp directories, and all sorts of horrifying stuff unsecured and facing the public internet.  Predictably, this has led to a rise in public exploitation of open devices and so-called "open directories". 

For example, there's even a fairly popular sub-reddit (which I won't name) devoted to posting people's latest "finds" in terms of such unsecured internet-facing media troves.   I found out about it while searching around to find out why shodan was scanning me.  This week, for example, someone posted some random person's unsecured calibre library of e-books and a library of all of beethoven's works on the subreddit.  The added bandwidth from all the reddit "interest" promptly crashed whoever's sites those actually were.  The whole "professionalization" of port-scanning makes me pretty queasy about having any kind of web facing anything without authentication these days.

If you do expose a public facing web service that you don't want to authenticate, make sure to monitor your traffic to ensure that internet randos aren't siphoning off TB of bandwidth that you may wind up being billed for (depending on your ISP).  JRiver's web service uses a high port number, which may escape some trivial scans, but many other media/high value services do the same thing so more port scanners are scanning more ports. If someone sees a 52199 port open and visits it in a browser, they'll see the Panel webpage, which makes it pretty clear there's media to be had there.  If they poke around in the menus, they'll find the MCWS API (which is self-documenting through the same menu), so very little additional intuition is necessary once they know the port is open.

It did occur to me that a little tick box on the library server options that would allow a password protected server to allow read only access to requests without a password could be quite useful, but I don't know if JRiver are able to add that.

This would make me very happy if it were possible.

[bob]

We're looking at adding an authentication level for read-only so you will get 3 states.

1. Unauthenticated, Read-only
2. Authenticated, Read-only
3. Authenticated, Read-write

This will require no changes on the client and just the addition of the read-only login/password on the server side and is compatible with the existing mechanism.

[Ekpen]

We're looking at adding an authentication level for read-only so you will get 3 states.

1. Unauthenticated, Read-only
2. Authenticated, Read-only
3. Authenticated, Read-write

This will require no changes on the client and just the addition of the read-only login/password on the server side and is compatible with the existing mechanism.

Greetings:

I used to run Ebony BBS when I lived in Independence, MO.
It was a DOS based BBS, with E-mail, files -utilities, drivers and DOS games such as Global war, Galactic war and Trade War.
This was GTpower BBS software, The design was very simple when it comes to access levels.
0-9 was used, 0 reserved for the Sysop or Admin.
When a user logs in for the first time, he or she will have to supply first name, last name and a system password will be given, then it was "test". As soon as the new user completes the initial entry of credential, the system will assign the next level of access say 8 . If the caller wants to contribute say $20.00, $35.00, or $50.00 a year, he will be assigned a higher access level that will enable the new caller to play games, or be given more time to interact with the Bbs. The access level are tied to time etc, but MC (does not need to be like this).
I am not saying MC should be designed in this matter, but the access level could be set up like this. These levels will define what a caller can do or not do, in the case of MC, it will be access to all or some "shared folders".

A database file will have to be created on the server.

Also, on the handheld side, in addition to media network credentials, fields should be added for First Name, Last Name, and Password.
If this feature is added, when someone logs in, the logger's name will be displayed on the server screen.
Note:
This is just a suggestion and also I am thinking out loud.

George

[stanzani]

We're looking at adding an authentication level for read-only so you will get 3 states.

1. Unauthenticated, Read-only
2. Authenticated, Read-only
3. Authenticated, Read-write

This will require no changes on the client and just the addition of the read-only login/password on the server side and is compatible with the existing mechanism.

Sounds a really good new!
any plan for delivery this feature? Hope will be part of 22

[KingSparta]

We're looking at adding an authentication level for read-only so you will get 3 states.

1. Unauthenticated, Read-only
2. Authenticated, Read-only
3. Authenticated, Read-write

This will require no changes on the client and just the addition of the read-only login/password on the server side and is compatible with the existing mechanism.

That Would Be Nice.

[bob]

That Would Be Nice.

There is an experimental version of this in current MC 22 builds.
You use it by enabling authentication on the server side and using

user:
readonly
password:
readonly

on the client side.

Feedback appreciated.

[justsomeguy]

I like the idea. Have tried it and seems to work.

I'd love to expand on it though. Will we be able to setup multiple login credentials and assign read-only, full or maybe even more granular permissions, like a kids account?  If so I'd like to be able to use that login info to build different views or filtering for clients depending on who they login as.

There is currently a "user" option in MC that can be used in views but it is lacking for use with clients, especially mobile clients. The MC server has to be set to a specific user, then that forces all clients(non pc) to only see files set to the one user. So if I setup a kids user and tag the files I want them to see with that user then everyone only sees the kids files. If I want to have access to everything then I have to set the MC server back to the admin account which then kids can see everything again. It had been suggested in the past to run two or more separate MC servers all set to different users. While that would work, it is not really an acceptable solution to run 2 or 3 computers for that purpose.

[mwillems]

I like the idea. Have tried it and seems to work.

I'd love to expand on it though. Will we be able to setup multiple login credentials and assign read-only, full or maybe even more granular permissions, like a kids account?  If so I'd like to be able to use that login info to build different views or filtering for clients depending on who they login as.

There is currently a "user" option in MC that can be used in views but it is lacking for use with clients, especially mobile clients. The MC server has to be set to a specific user, then that forces all clients(non pc) to only see files set to the one user. So if I setup a kids user and tag the files I want them to see with that user then everyone only sees the kids files. If I want to have access to everything then I have to set the MC server back to the admin account which then kids can see everything again. It had been suggested in the past to run two or more separate MC servers all set to different users. While that would work, it is not really an acceptable solution to run 2 or 3 computers for that purpose.

This won't 100% solve your problem, but a useful tip:  setting the server to a user only controls what user client instances start in.  Desktop clients can change the user to something else that doesn't match the server default.  So, for example, I leave the server set to the Guest/Kids user, but when I open up MC myself I change to my user on the client so I can see everything. 

It doesn't solve the mobile client issue unfortunately; I agree it would be nice to have a full blown user system from soup to nuts.

[stanzani]

There is an experimental version of this in current MC 22 builds.
You use it by enabling authentication on the server side and using

user:
readonly
password:
readonly

on the client side.

Feedback appreciated.

I cannot find this. It is under options > Media Network?

please help

[marko]

You enable authentication on the server. Set a user name and password.

Clients that connect using that user name and password can make changes to the server library, however, if, when connecting from a client, instead of your user name and password, you input "readonly" as the user name and password on the client, the server should allow you read only access.

[eezetee]

This feature works great. Thank you!