Add HTTP Refferer to new 'streaming' media content + llLoadURL()

Could we get a secondlife://sim/x/y/ type HTTP-referer set on streaming media content (such as that used in land parcel streams, and the new media-on-prims system), the same would also be availible through llLoadURL()

This would let us do things like dynamically generate 'you are here' maps in SL through the media options, or use it to check if a parcel is authorised to have that stream loaded.

-Adam

signed

And possibly shut down unauthorized uses of a stream since the URL can't be hidden.

Cool idea for mapping but for authentication referer is easily spoofed.

I would also like to see this implemented.

It could be spoofed, but not from inside SL. Another land owner couldn't put the same URL on their plot.

Yeah, it would be ideal however pretty sure this goes through QuickTime and there isn't anything SL can do about it.

For the mapping thing, why don't you just use llGetRegionName .. llGetPos .. (or whatever) and tag it onto the query string?

Also, in terms of security .. it's not that hard. just hash the current time as a security code (maybe in 1 minute increments, and the other side should check forward and backward in case you don't have total synchronization).

If someone wanted to steal your streaming URL they'd have to do it every minute. Completely unworkable.

blaze may have a point on the fact that it all goes trough quicktime, but who knows, maybe the quicktime API has some code-fu that lets you do it.

Unfortunatly, this may also be true for llLoadURL - since SL only passes the URL to the system-defined browser. The referer will probebly end up being the last page you've been to no matter what.

I still think that this would be a nice thing to have though. And, while you can "just use llGetPos", having built-in solutions like this are always better then having a script-based workaround.

blaze is correct - there currently isn't a way to do what you want.

i understand it's important though and i'll keep it in mind as that part of the app develops.

I suspected the API was rather limited (I looked at it for both user-agent setting, and refferer); so I have another suggestion to achieve the same thing:

%SL_POSRAND%

That string, when inserted into a URL will be dynamically subsituted for the following (when placed into a URL; the random number is generated by the client, so all the connecting users have a unique ID here):

x=global_x&y=global_y&z=&global_z&rand=<random 64 bit integer in hexadecimal>

Now:

If someone wants to copy a URL, and decides to use
http://steam/?x=256200&y=240096&z=20&rand=AE87F372CA2320B

Then all the clients connecting from that parcel will have the same random number attached there; the server software can then filter that random number out; the only way to avoid this would be to have only one client connect (and hence not trip the alarm), since changing the media parcel by script would cause everybody to connect with the same random number, and it will trip the alarm again, blocking it.

It's a little complex; but it could work as an effective solution, and since using the %SL_POSRAND% keyword in URL's optional, it wont break anything.

-Adam

interesting idea adam - we're very close to release now and so no new features are being added to the codebase - i'll add your comments to my list of things to do and make sure it's brought up in discussion about the next (minor) version.

cheers.

cal.

is there a reason the stream URL can't be invisible to people who don't have write access to it? seems like a simple thing to me.

the stream is invisible as far as the Second Life client is concerned - it's very easy to discover using built in operating system commands which is something we can't stop.

You could build a flash app with a PHP backend and use my flash hacks. That way you could just parse the location data into a URL and send it to a PHP script that will update a flash app that will zero in on the user location, then use the media commands to update to QT stream and show the updated flash file.

Yeah, Adam should know this which is kinda weird.

I can understand the URL security, but his idea can be written in LSL, so I don't understand why he wants to impact a pretty busy LL crew when he can write the code himself..

If you had to set the url every minute or so through LSL wouldn't all the clients have to keep reconnecting, resultings in a lot of breaks in the music?

Also he said :

Nah, you don't have to reset the url.

It's just when you go to make the call to the stream, the url response can reject the script if it doesn't have the time hashed correctly.

In fact, if you're script isn't getting restart constantly, thieves would only be able to steal the stream (even via netstat!) only when it actually gets reset.

I guess if users could reset the stream at will, the could fly over and reset the stream, and if they can make it back to their parcel in 60 seconds they could use it. But only for the next 60 seconds. They'd have to fly back and reset it again in order to get the next URL.

Though, I suppose they could have a friend sit in the parcel, sniff the stream, and have them reset it.

Anyways, in the end, waaaay too much work to steal something that probably really isn't worth it.

I requested this last week and got "GOOD IDEA FOR 1.7"

Please simply hide the URL.

Not everyone has easy access to the LSL or server-side scripting/coding/filtering skills or features/products needed to be able to check URLs.

Your usual "www.isp.com/~username" accounts don't come with anything more than webspace. But that doesn't mean that Mr. or Mrs. username's isp needs to be slashdotted by piggybacking bandwidth stealers.

That wont work because changing the stream every X seconds to rehash the time will disconnect all the users currently on the stream, breaking whatever streaming media you are trying to display.

This method would be unclonable with LSL which was the intention. If it's not doable with inworld tools, then people wont be able to steal the stream providing the server is setup correctly (which is really not too hard).

Implementing this shouldnt be too hard, just a simple case of a string replace before passing it to the media URL system. (simple, providing the client has some form of global or easily accessible method of getting the avatars position, which I would assume is the case.)

-Adam

You don't have to re-connect .. think about it adam.

When you connect, you hash the time. If the server does a similar hash and they don't match, you reject the attempt to connect to the stream.

If you're worried about people joining the party late, then just up the time window hash to the length of the stream.

Someone could, in theory, come along and sniff the stream at that point and if they were fast enough could copy the stream over to their parcel. However, the next time they'd want to play the stream they'd have to do that all over again.

Anyways, I'm sure there are many other approaches that would work as well.

Anyways, I really doubt this is going to be an issue because people clever enough to netstat the stream are usually clever enough not to have to steal things.

Yes, but to update your own parcel's stream url with the proper time code, you'll have to set the parcel url with a script, which will cause the clients to all reconnect to that stream.

Try a script that sets the url with a variable in it. Every time it updates your parcel's url, the people on the land will reconnect. Unless you meant give every person a seperate url when they enter your parcel a unique code... ? Which is impossible because you can't set this individually. Not sure what you're saying I guess.



There's nothing really tricky about netstat...but will only give you the server address, you'll need a sniffer to determine the actual url. Still, it doesn't take much to figure out a simple sniffer either.

Yeah, but you don't have to update until a) the stream is finished or b) someone starts the stream.

Ok.. then you need to have LSL keeping track of when to reset the stream, maybe xml-rpc, and it won't work for live feeds. Also, everyone probably won't be at the exact same point in the stream, so you'd have to account for people that are behind. You might be able to get *something* with this, but I wouldn't consider it the "right" way to go about fixing the problem.