Print

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

[hoyt]

This is cool.  I really like this idea and am happy to see it getting movement.  Perhaps my situation is different, but when I do generate link it makes the IP address and internal port, which is different than what I want/ can share.  I have my MC server behind a proxy server, serving any external link via HTTPS that way.  So I get:

http://external_ip:52199/MCWS/v1/

But what I need is:

https://external_fqdn:52200/MCWS/v1/

I might be the only one doing this, but I don't have MC managing my fqdn keys because I didn't want to paste the new keys every 90 days.  This way my webserver kicks off certbot-renew every X days and gets the new certs when they expire.  That webserver then manages my external requests.  It would be nice to supply those data points to MC in the prefs "when sharing make my external address be X and my external port be X, and make them be HTTPS Yes/No."  Like I said, I might be the odd-man out here, but as long as MC would make a shareable link, aka Google Drive, then I think that's very cool.

[Matt]

Tonight's build does a lot of work here.

Encrypted the URL so guessing isn't possible anymore based on the suggestions above.

Renamed the feature "Share" based on Jim's suggestion.

Made a way to reset your share key based on feedback from Hendrik.

Thanks for all the help.

[jmone]

Looking good:
- New Key method works
- Invalidating the Key works

Looks like (for Video) only MP4 plays in Web Browser, the other types are not shown in the Web Browser but are download automatically.  So (for video):
- Would using Hendrik's new MCWS API for Video Streaming like that used for JRemote2 be a better idea?  I expect this should then work with all video (including compound videos like DVD / BD etc) on any device regardless of Formats, Bitrates etc (and the Bitrate should be better for streaming)?
- If the above is added then a "nice" to have would be for the Download Button option to allow for either the converted stream or original but.... I'd just be happy with the above.

...or should the "share" MCWS call be a subset of the existing GetFile ? 

[JimH]

I removed a couple  of posts.  Please put requests for other features on the MC27 board.  This isn't a private request board.

jmone gets a pass this time.

[leezer3]

This may be a thought too far:
Perhaps consider 'hiding' the fact that our share key is MCWS at all?

Separate on port or something?

The first draft showed that its possible for a malicious actor to manipulate the MCWS call.
Expose as little attack surface as possible

(Or possibly being paranoid)

[JimH]

Not paranoid.

Matt,
It works for me.  Thanks.

I'd like to be able to decide which address to copy.  I also don't think there's any point in displaying it.  Maybe the IP, but nothing else.

A window that had two buttons would work:

Please choose which link to
copy to your clipboard.

[Local]   or   [Internet]


Or maybe someone else has a better idea.

It's great to have the help.  Thanks.

[Hendrik]

How useful is the local sharing?
Wouldn't the internet link just work in the occasion you need something local? Most routers would be smart enough to just route that request internally in your network.

[jmone]

Most routers would be smart enough to just route that request internally in your network.

Yes.  I Tested a 150mbs Video using the external link and while my router traffic reported it on both the Upload and Download the traffic was just doing a U turn and not hitting the Modem (my up link from the modem is 50bps so such a stream would gag).

[zybex]

Cool Encryption looks good. Just a note: please ensure that the encryption key is unique for each PC or MC install. This should not be the same as the Access Key... maybe you can generate a random key on first time use.

Two details to fix:

1. The Base64 string is broken by CRLF every 64 chars - 2 lines are actually copied into the Clipboard

2. The Base64 string is using the default mapping with fwd-slash, Equal and Plus characters, which make up a slightly invalid URL (still works, but not ideal). The Base64 string should be URL-Encoded (%2F) or use a Base64 character mapping without those chars.
 
Regarding the local vs remote URL... I agree that the remote one is what makes sense.
What about adding a setting/RegistryKey to add an FQDN? If it's blank, then MC would use the public IP; if it's defined then it would use that instead.

[JimH]

How useful is the local sharing?
Wouldn't the internet link just work in the occasion you need something local?

Testing.  Large network like a university or a business.

Most routers would be smart enough to just route that request internally in your network.

I didn't know that.  Is it safe to assume it's 100%?  I'd rather not find out the hard way.

[JimH]

Regarding the local vs remote URL... I agree that the remote one is what makes sense.
What about adding a setting/RegistryKey to add an FQDN? If it's blank, then MC would use the public IP; if it's defined then it would use that instead.

Interesting idea.  Do we know the FQDN?  If the user has to set it, we end up doing network support.  Local vs Internet is clear and simple to explain.

[zybex]

Testing.  Large network like a university or a business.I didn't know that.  Is it safe to assume it's 100%?  I'd rather not find out the hard way.

It works only if you add the port-forward entry for MC on the router, so that it knows which device to forward the connection to. So in effect, you still need to have an open port accessible from outside. Also, not all routers do this U-turn (though most do)

[zybex]

Interesting idea.  Do we know the FQDN?  If the user has to set it, we end up doing network support.  Local vs Internet is clear and simple to explain.

No - MC could do a reverse DNS lookup to find the FQDN but that won't work for dynamic domains like "myhome.dyndns.org".
The user would need to somehow give it to MC - if one is knowledgeable enough to have a DynDNS, one knows how to use it (I hope). The alternative is to have to edit all MC Sharing links to replace the IP with the FQDN.

The thing with external IPs is that they change, so the links become invalid. Only companies have fixed IP addresses. Having the option to use a dyndns domain is nice; I bought a domain name with dynamic IP support and use it to reach my home services.

[Hendrik]

Cool Encryption looks good. Just a note: please ensure that the encryption key is unique for each PC or MC install. This should not be the same as the Access Key... maybe you can generate a random key on first time use.

Thats how it should work. I also asked Matt to make a button to reset it, I think that made it into the build as well.

[JimH]

The thing with external IPs is that they change, so the links become invalid. Only companies have fixed IP addresses. Having the option to use a dyndns domain is nice; I bought a domain name with dynamic IP support and use it to reach my home services.

Our Access Key sever keeps track of the outside address.  We use that server for this new sharing feature.

[zybex]

You can't use that, really... the generated Sharing URL is a public address which does not link in any way to JRiver's access keys. It's either an IP address or a domain name.

To use your AccessKey server, the URLs would need to be something like "http://sharing.jriver.com/blablabla?File=EncryptedData"; the encrypted data would need to contain the target AccessKey, and your server would then need to redirect the HTTP request to the actual IP of the user. All accesses would have to go through your server.

Unless you want to provide a Dynamic DNS Server service to all your customers With domain names like "accesskey.mc.jriver.com", which would resolve to the user's IP.

[hoyt]

No - MC could do a reverse DNS lookup to find the FQDN but that won't work for dynamic domains like "myhome.dyndns.org".
The user would need to somehow give it to MC - if one is knowledgeable enough to have a DynDNS, one knows how to use it (I hope). The alternative is to have to edit all MC Sharing links to replace the IP with the FQDN.

The thing with external IPs is that they change, so the links become invalid. Only companies have fixed IP addresses. Having the option to use a dyndns domain is nice; I bought a domain name with dynamic IP support and use it to reach my home services.

Yeah, that's how my setup is.  I use https://home.mydomain.com:52200 to get to MC.  My router forwards 52200 to my webserver at 192.168.x.x.  That webserver then listens on 52200 and checks the SSL certs and proxies the info to my jriver instance at 192.168.2.103.

Code: [Select]

<VirtualHost *:52200>
    ServerName home.mydomain.com

    Include /usr/local/apache2/conf/options-ssl-apache.sslconf
    SSLCertificateFile /usr/local/letsencrypt/live/fullchain.pem
    SSLCertificateKeyFile /usr/local/letsencrypt/live/privkey.pem

    ProxyRequests Off
    ProxyPass / http://192.168.2.103:52199/
    ProxyPassReverse / http://192.168.2.103:52199/
    ProxyPreserveHost on

</VirtualHost>

This works well, but it means MC has no idea what port to use and doesn't know my domain name.  MC doesn't even have my SSL keys, so you couldn't determine it that way either.  I would really need to supply these items to MC as a setting.

[zybex]

There's an option to "Enable SSL" under Settings->Media Network, using port 52200. You can provide your certificate as well. So I think you can skip your proxy server.

[JimH]

You can't use that, really... the generated Sharing URL is a public address which does not link in any way to JRiver's access keys. It's either an IP address or a domain name.

No, you don't use the Access Key, but yes, we use our Access Key server to get your current IP address.

[hoyt]

There's an option to "Enable SSL" under Settings->Media Network, using port 52200. You can provide your certificate as well. So I think you can skip your proxy server.

But then I have to copy my cert files every 90 days to my MC server and re-include them.  This way, Letsencrypt takes care of it begin-to-end automatically.

[zybex]

No, you don't use the Access Key, but yes, we use our Access Key server to get your current IP address.

Ah, OK. I misunderstood. Still, we can't use it as a general purpose dynDNS, so it would be nice to allow for that option.

[hoyt]

I tested out expiring the links and that worked.  Good idea.  Does that mean that I can somehow generate a report in MC of all the links I've created?  Anyway to manually manage that, ie - expire one link, but not all?  Or when sharing, set a default expiration?  OneDrive does this well.  When you go to make a sharable link, you can set an automatic expiration after X days.

[jmone]

FYI, I have both a static IP and also a DYNDNS entry simply to keep a simple to remember FQDN, but I found that while:
- http://123.123.123.123:52199/MCWS/v1/Share/Get?File=abcdef (works)
- http://mine.dyndns.org:52199/MCWS/v1/Share/Get?File=abcdef (does not - I get a "the server unexpectedly closed the connection)

[jmone]

1. Changed: Added URL escapement to the share URLs.
4. Changed: When sharing, a choice is offered about what link to place on the clipboard.

Both work fine.

[Hendrik]

Looks like (for Video) only MP4 plays in Web Browser, the other types are not shown in the Web Browser but are download automatically.  So (for video):
- Would using Hendrik's new MCWS API for Video Streaming like that used for JRemote2 be a better idea?  I expect this should then work with all video (including compound videos like DVD / BD etc) on any device regardless of Formats, Bitrates etc (and the Bitrate should be better for streaming)?
- If the above is added then a "nice" to have would be for the Download Button option to allow for either the converted stream or original but.... I'd just be happy with the above.

That is not really related. If you want to be able to watch every video in-browser properly, it would likely have to produce some kind of website with an actual video player component on it, similar to Panels player page.

[JimH]

That is not really related. If you want to be able to watch every video in-browser properly, it would likely have to produce some kind of website with an actual video player component on it, similar to Panels player page.

Couldn't the server convert?

[jmone]

That is not really related. If you want to be able to watch every video in-browser properly, it would likely have to produce some kind of website with an actual video player component on it, similar to Panels player page.

...but you already have that new high quality AutoFPS MCWS call that will produce a webplayable stream that is used by JRemote2 etc.  Only about 20% of my Videos are MP4, so the other 80% will not play with the current method, but 100% will if using your new MCWS call.  Without on-the-fly conversion then I'm not sure this public URL feature is all that useful (to me), unless I make a MP4 versions of everything I want to share first (which is an option I guess). 

[jmone]

Let me take a step back from the details to the original Idea (aka MC Youtube).  #1 It has to be simple, and #2 it has to always work
- Example 1: I've just shot a video of the family at Christmas and I want to share a link of that one item with the Family. 
- Example 2: I was then asked by my brother stuck in lockdown in the UK for some really old video from when we lived in the US (about half a dozen different videos) so I want to share a link to that set of videos

The link(s) just needs to work regardless of
- What Container & Codecs they are in MC,
- What Device they are watching it on (Phone, PC, etc), and
- What Bandwidth is available for the stream to play reliably.

Suggestion on the specifics:  I think (for most users) it would work best if they did not have to manually create a "streamable version" but for MC to do this on the fly as needed, based on a profile like we have now with for both
- "Client Options (when connected to a Library Server)" and with
- "DNLA" Clients

.... so something like this (but I don't profess to know the details of what makes sense for the profiles)


 

[jmone]

That is not really related. If you want to be able to watch every video in-browser properly, it would likely have to produce some kind of website with an actual video player component on it, similar to Panels player page.

You may be right, especially if you want an end user to be able to "Browse" a selection of shared content.  I would have thought a link to a single video would be fine however (or am I missing something)?

[hoyt]

That is not really related. If you want to be able to watch every video in-browser properly, it would likely have to produce some kind of website with an actual video player component on it, similar to Panels player page.

Why not use Panel for this?  Maybe there's s good reason, but that would certainly make sense for the "next" of a playlist.

[Hendrik]

...but you already have that new high quality AutoFPS MCWS call that will produce a webplayable stream that is used by JRemote2 etc.  Only about 20% of my Videos are MP4, so the other 80% will not play with the current method, but 100% will if using your new MCWS call.  Without on-the-fly conversion then I'm not sure this public URL feature is all that useful (to me), unless I make a MP4 versions of everything I want to share first (which is an option I guess).

The new API does not change any of that. You could do the same with the old one. Its entirely tangential to any sharing here.
If you want video to play properly in a browser, it needs to be wrapped in some kind of website. Thats maybe something Brad can work with Matt, as he did that for Panel.

[jmone]

Sorry, I'm clearly missing a key point in my understanding (not to hard for me to get confused!).

Couldn't the single shared link present a websafe transcoded steam instead of the original file?  And if so, would it not make sense to use your new improved code?

We're working on a set of video streaming improvements for MCWS and JRemote2 for Android.  They will arrive later this month.

All these changes are designed for cases when streaming video to the remote device, ......

[Hendrik]

You keep asking the same question and i have no new answers. The new API is entirely unrelated to any questions in this thread. If you want universal video playback, it needs to return an actual website that wraps the stream in soem fashion. Browsers are terrible video players, thats why they get fancy Javascript components to help them along.

[zybex]

@Jmone: Why transcode something, forcing the user the have a [relatively] powerful server and suffer quality loss, plus noise and heat on the server side, when you can have direct playback with Hendrik's solution: a Player component on the webpage that streams the original file and just plays it, with support for most formats. I hate transcoding of any kind.

The Sharing mechanism is the first step. With that in place JRiver can build on it and add the player webpage and other features.

[jmone]

Apologies Hendrik.  I'm not trying to be difficult but I really really don't understand.  I must be missing something fundamental, that I am trivialising something, or that I'm asking the wrong question.  I'll have one more crack at trying to understand, then I'll shut up.

From what I can tell:  Matt's Share Link streams out an MP4 Video that plays in a Web Browser.  It works.  No fancy Jacascript or Website required.  While is simple, elegant & efficient, it is not universal as it appears the video must be an MP4 and that the bitrate of the original MP4 may be too high to stream out.  If that is correct;

The bit I don't understand is: what is the issue with Matt's share link using an on the fly transcoded stream instead of the original?

[jmone]

@Zybex.  If the bitrate of your video is higher than your bandwidth you will need to transcode for real time playback.

[JimH]

jmone,
I sent this to Hendrik earlier:

"Right now, we can convert on-the-fly for Gizmo and JRemote2.  I know the server has to do it.  Why could we not have a URL that signaled MC that conversion was needed?"

Hendrik, please reply here if you want to.

[Hendrik]

There is no good on the fly conversion format that a browser can simply play out of the box, like mentioned above, Browsers are actually pretty bad video players. Thats why you need a JavaScript web player around it like we have in Panel that manages the playback, ie. a website that embeds the player.

Thus, there is no URL we can generate that "just plays" right now without several deficits. The streaming conversion is focused on actual players on the users end, like it exists inside JRemote2, or even inside Panel, but its not something a browser can just play without help.

This doesn't mean it can't be done, it just requires a bunch more work. Thats why I suggested involving Brad above, since he made this for Panel and has experience with providing a web site through MC.
If we intend the share feature to primarily be for something you are supposed to play, and not download, then a player page that comes up might make sense for all media types, as it avoids hoping that the browser does the right thing even with eg. audio.

[jmone]

Thanks Hendrik. 

[backinbox] This was the bit I did not understand: "there is no URL we can generate that "just plays" right now without several deficits".  I'd just "presumed" that if a static MP4 would play, then an on the fly one would as well, and that the new HLS default profile was the ticket to do so.  Sorry for the Angst in getting it through me thick head. [/backinbox]

I also agree, that exposing the MC Web Server would be a much more capable and scalable soln.

[jmone]

The other thing I use a web server for is to host pics to be used to embed IMG links in forums (especially when you can't attach).  Lets see if the share links works for this.

Image imbedded between the lines using "Insert Image Link" option on the forum sw
--------------------------

--------------------------
edit - Nope.  just above is the following wrapped in the img tag (img)(/img) (but with square brackets) but nothing appears

http://144.137.208.82:52199/MCWS/v1/Share/Get?File=mwZDhP%2BGhvcquLv5kBISJNzON2X5ohUoz0Ll1b2a9emPSTKGLRjyoRxg1F5uMoYC%0AICd0bok%2BZ7cUrJmzKQcSDg%3D%3D

[Hendrik]

It doesn't show your image because its http (not https), and mixed content is no longer allowed in any modern browsers.

[JimH]

The other thing I use a web server for is to host pics to be used to embed IMG links in forums (especially when you can't attach).  Lets see if the share links works for this.

Image imbedded between the lines using "Insert Image Link" option on the forum sw
--------------------------

--------------------------
edit - Nope.  just above is the following wrapped in the img tag (img)(/img) (but with square brackets) but nothing appears

http://144.137.208.82:52199/MCWS/v1/Share/Get?File=mwZDhP%2BGhvcquLv5kBISJNzON2X5ohUoz0Ll1b2a9emPSTKGLRjyoRxg1F5uMoYC%0AICd0bok%2BZ7cUrJmzKQcSDg%3D%3D

Maybe because it's not an image.  Try making it a simple link.

[zybex]

What do you think of adding 2 fields:

[Number Plays (Sharing)] or [Shared Plays] - increases when a share URL is accessed ([Number Plays] should also increase)

[Shared] - Bool. When user generates the Sharing URL, this field gets checked. If the user unchecks it the file cannot be played using the Sharing URL. This allows:
- un-share a single file instead of having to invalidate all shares
- temporary un-sharing
- easy list/filter for currently shared files

When a Share URL is accessed, MC just needs to check if this field is checked. Clearing the ShareKey could uncheck this field on all files automatically.

[Matt]

[Shared] - Bool. When user generates the Sharing URL, this field gets checked. If the user unchecks it the file cannot be played using the Sharing URL. This allows:
- un-share a single file instead of having to invalidate all shares
- temporary un-sharing
- easy list/filter for currently shared files

I like this idea.  I'll work on it.  Thanks!

[hoyt]

[Shared] - Bool. When user generates the Sharing URL, this field gets checked. If the user unchecks it the file cannot be played using the Sharing URL. This allows:
- un-share a single file instead of having to invalidate all shares
- temporary un-sharing
- easy list/filter for currently shared files

That would accomplish what I was thinking here fairly elegantly:

I tested out expiring the links and that worked.  Good idea.  Does that mean that I can somehow generate a report in MC of all the links I've created?  Anyway to manually manage that, ie - expire one link, but not all?  Or when sharing, set a default expiration?  OneDrive does this well.  When you go to make a sharable link, you can set an automatic expiration after X days.

[zybex]

That would accomplish what I was thinking here fairly elegantly:

I tested out expiring the links and that worked.  Good idea.  Does that mean that I can somehow generate a report in MC of all the links I've created?  Anyway to manually manage that, ie - expire one link, but not all?  Or when sharing, set a default expiration?  OneDrive does this well.  When you go to make a sharable link, you can set an automatic expiration after X days.

I did propose the [Shared] field and an Expiration mechanism already on post #13 ... I need to learn how to write more concise posts so that people actually read them

[jmone]

Nice - +1 for the Check box and a count field (so you have some indication that the file has been accessed or not).

[marko]

The generated link is super ugly... Would it be hard to format it, say, with the file name?

[zybex]

The URL needs to contain the FileKey in a secure way... adding more info is possible, but only makes it longer.

Here are 2 alternatives for prettier URLs:

1. Youtube-like short identifiers: these would be random generated, stored in a [ShareKey] field of each shared file:

Code: [Select]

http://my.mchome.net:52199/Share?File=ZaV5zK3P1XeCollisions would need to be prevented. Security would come from the randomness of the identifier, hard to guess a valid one.

2. [sort of] Human readable URLs with a secure Signature for validation:

Code: [Select]

http://my.mchome.net:52199/Share?File=123456&Name=The%20Croods%3A%20A%20New%20Age&Sig=5zK3P1XeThe &Name= parameter is entirely cosmetic/optional (can also be added on the first method above). The &File has the actual file Key to share, and the &Sig has an encrypted hash that must match some server-generated hash for this URL/File.

In the end, the URL is not meant to be pretty. You can use some URL-shortener like bit.ly to create nicer URLs if you like.

[jmone]

It doesn't show your image because its http (not https), and mixed content is no longer allowed in any modern browsers.

Makes Sense.  So is there a way of adding a Cert and generating a HTTPS link that would then work for embedding PICs in a forum like this?

Here is a sample link from my MC instance for testing if anyone has some bright ideas?
http://144.137.208.82:52199/MCWS/v1/Share/Get?File=mwZDhP%2BGhvcquLv5kBISJNzON2X5ohUoz0Ll1b2a9emPSTKGLRjyoRxg1F5uMoYC%0AICd0bok%2BZ7cUrJmzKQcSDg%3D%3D