I need to add a video player to my website that will play content from video streaming (YouTube Live, Azure Media Services or any streaming services from a hosting company).
The player will be visible only to authenticated users, but as the streaming URL won't change, I needed to hide it from the user (maybe using DNS configuration in my domain or something else).
Do you know a way to protect the streaming URL?
Given the requirement that you do not want people to see the video even if they have gotten the URL (“so people that don't have signed up to my Web seminar won't be able to watch it”), and given that the player is available only to authenticated users, I have a suggestion:
Create a unique URL at your domain for each video stream.
When a user hits the URL of the stream, do the following:
Use your authentication logic to see if the user has permission.
If the user has permission, use a 301 or pass the stream through to the player.
If the user does not have permission, redirect the user to the login page (or whatever).
Repeat.
From experience, once you get much beyond that level of complexity you need to start looking at services that do this as their business model. Otherwise you run the risk of falling into the rabbit hole.
The caveat here is that once the user has the stream, a motivated person can still identify the source URL and do whatever with it.
If you want to protect your content, you have to encrypt it and decrypt on a fly for authenticated users. Content key for decryption might be associated to specific media content and have expiration. In this case even users who know the streaming uri, have to obtain content key for decryption. You can use clear key encryption or DRM services to archive this scenario. https://azure.microsoft.com/en-us/services/media-services/content-protection/ - contains overview of content protection options in Azure Media Services.
Nothing stops user to open any browser dev tool and copy destination uri if you just masking url by providing redirect.
Related
I have stored a video file in BLOB storage. I need to stream this video but, I do not want users to go into developer mode and copy/paste URL on a browser so they can download it.
I have tried many ways to control this but I have failed. I used SAS token with an expiry, but, users are still able to download the content within that expiry period.
My latest approach is to hide the SAS Token enabled video URL behind Azure API Management Service. This will give me a different URL (which is not the BLOB storage URL) which I will expose on the HTML page. Will this approach work ?
NO, we cannot hide the backend information in a Web. You can’t hide anything that your app running on a clients Browser. Instead of that you can secure your backend service.
There are some alternate ways to do that, but we don’t hide anything on a web.
1. Mask URLs in content
The redirect-content-urls policy re-writes (masks) links in the response body so that they point to the equivalent link via the gateway. Use in the outbound section to re-write response body links to make them point to the gateway. Use in the inbound section for an opposite effect.
<redirect-content-urls />
Refer for Mask URLs in content
2. Set backend service
Use the set-backend-service policy to redirect an incoming request to a different backend than the one specified in the API settings for that operation. This policy changes the backend service base URL of the incoming request to the one specified in the policy.
<set-backend-service base-url="base URL of the backend service" />
Or
<set-backend-service backend-id="identifier of the backend entity specifying base URL of the backend service" />
Refer Set backend service
Other wise you can encrypt your video data to secure a backend
To know the possible ways see here
If a client has a valid SAS can access your storage account that was permitted by the SAS. It’s important to protect a SAS from malicious or unintended use. For that use discretion in distributing a SAS, and have a plan in place for revoking a compromised SAS.
Refer: SAS for blob
When using the RingCentral Call Log to access call recording audio files, a contentUri is provided in the response.record[x].recording object which points to a binary form of the call audio. The API's Authorization header is still necessary to retrieve this file.
Is it possible to play this back in a web app using a HTML5 audio element so we don't have to host/upload to call audio to our own system. It seems like this would need to avoid using the Authorization header and supply authorization in some other fashion. For example:
<audio src="https://media.ringcentral.com/.../recording/{recordingId}"></audio>
More information on the HTML5 audio element is available here:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio
It is possible to playback a RingCentral call recording with using an HTML5 audio element without downloading and hosting the audio file yourself. Authorization is still required so it must be passed using an approach other than the HTTP header.
Two approaches include:
1) Access Token in Query String
You can append the access token to the media URL as a query parameter so you have something like:
<audio
src="https://media.ringcentral.com/.../{recordingId}?access_token=MyToken">
</audio>
A caveat with this approach is that the URL will stop working when the access token expires, typically in one hour or less. This is useful for ephemeral links such as time-sensitive links in a chat stream, however, less so if the link needs to be retrieved later. For that, see the following approach.
2) Access Token in Cookie
If you want a permanent URL that doesn't expire, you can use a proxy service that manages the authentication for you. One way to do this is to use the RingCentral cookie-based Implicit Grant OAuth flow to transmit the access token to the proxy service. This way, when attempting to retrieve a media file via URL (without token), the proxy service can check if the cookie is present and valid. If it isn't, the proxy service can prompt for a successful Implicit Grant login before forwarding to the call recording media file. An example implementation of this is available here:
https://github.com/tylerlong/permalink
I'm a hobbyist student developer playing around with the Actions on Google to create a simple "text adventure" game on Google Home. Since Google Home will be speaking to the player rather than the player reading the text, I'm hoping this will create an experience similar to the "Dungeons and Dragons" roleplaying game, with the computer working as the "Dungeon Master." With the natural language assistance offered by API.AI and Actions on Google, it seemed like a good fit, since the player can respond "naturally." Here's an example of an Amazon Alexa skill that does essentially what I'm going for.
However, every time I boot up the game, it's always a new game. I'd like to store a savegame with the user's previous state in a JSON file hosted on the user's Google Drive -- Since I'm just a student doing this for fun, I don't actually have an official website or anything beyond a free Heroku server I'm running the app from, making storing saves on my end pretty much out of the question.
I've walked through the Google Drive REST quickstart for Node.js, and I've gotten that working in the console just fine. The only problem is in that quickstart, the user has to click a link to authorize the application to read the stuff in their Google Drive account, and I'm not sure how I'd be able to "click a link" and give back an access token via voice on Google Home.
Is there a way to do this via Google Drive? Or is there a better way to provide persistent data between sessions? I don't normally work in web development, so any help would be appreciated.
The bad news is you won't be able to get away from the need for a user to use his web browser to authorise your app to access his Drive.
The good news is that you only need to do this once. When your app requests authoirsation, it should specify "offline", which will result in you being given a refresh token. You should save this somewhere in your database of users. Whenever you need to access the user's Drive, you can use the saved refresh token to request an access token and you're good to go.
You have a few problems that you need to solve here, and while they seem related, they're not as related as you might hope:
You need to get authorization to access a user's Drive space
You need to authenticate the user's Home (so you know this person has come back)
You have to connect the two relationships - so you know what Drive space to use for the Home device that is talking to you
You've found the answers to (1) already, and as noted, you'll need to use a browser for them to authorize you to access their Drive. You'll then store the refresh token and will be able to access it in the future.
But that is only part of the problem. Home does not provide you access to the user's Google account directly, so you'll have to manage your own account mechanism and tie it to Home. There are a few solutions here:
Home provides anonymous user identity in the JSON sent to your webhook. You can access this using getUser().user_id if you're using the Actions API library, or access this in the data.user.user_id field in the JSON. While this is similar to a browser cookie, it only stores the user ID and can't store additional data. There is also no concept of "local storage". On the plus side, this ID is consistent across devices.
You can request user information such as their name and address. But it doesn't have anything unique or account information, so this probably isn't useful to you.
You can implement an OAuth2 server and do account linking. Note that this is the other side from what you need to do with Google Drive - you'll be providing the access and refresh tokens to authenticate and authorize access to your account and the Google Home device will send these tokens back to you so you can determine who the user is. You don't actually need to store account information - you can provide token information using JSON Web Tokens (JWT) or other methods and have them store account information in a secure way. Users will use the Google Home app to actually sign-in to your service as a one-time event.
In order to handle (3), you may be thinking that (1) lets you get tokens and the OAuth solution for (2) requires you to hand out tokens. Can the two be combined? Well... probably, but it isn't as straightforward. You can't just give the Google OAuth2 endpoints to Home - they explicitly block that and you need to control your OAuth2 endpoints. You may, however, be able to build proxy endpoints - but I haven't explored the security implications of doing so.
I think you're on the right track - using Drive is a good place to store users' information. Using Home's account linking gives you a place where they have to come to your web site to authenticate and authorize their Home, and you can use this to do the same for their Drive.
I need to create a third party opt-out cookie and I am confused on how to do it? I will have an opt-out button on my webpage and when someone clicks it then it should opt out so if I see that cookie on another website then I will not do anything with that cookie id.
1) Do I need to get the user cookie and store int in my database?
2) Do I need to place a cookie that will tell me if that user opted out?
Basically..I am confused about the workflow on best practice.
Thanks
so if I see that cookie on another website
You will never see that cookie on another website which is on a different domain because cookies cannot be shared between domains. So I guess that your best bet is to store this information into a database. Then the other site might either directly access this database (depending on your architecture) or you could expose it as web service that this other site will consume to know whether a given user has opted out.
Now if on the other hand the sites are on the same root domain (like foo.example.com and bar.example.com) you could share a cookie between them. You just need to set the Domain property of the cookie when generating it to the root domain (.example.com).
This is somewhat of a newbie question I'm sure and I hope the community will excuse me for not knowing this (or not knowing the appropriate search terms to resolve my question).
So, this is the deal: I'm running a small webpage with a small amount of visitors. I've written the whole page in HTML and CSS myself and I host it in my private DropBox (http://dl.dropbox.com/u/3394117/Hemsida/Psykofil/Index.html).
I've bought the domain name "www.psykofil.org" from Loopia (www.loopia.se) and I've directed this domain to the index.html file referenced to above.
Now, this is what I want to happen: I have three different places you can go to on the page (you choose where to ge through a menu on the left). When one of these links is clicked, it takes the user to another .html-file. What I would like to happen here is that this is seen in the adress field so when he or she clicks on "x", it should say www.psykofil.org/x on top. Also, when he or she navigates away from the webpage through a hyperlink I would like the adress field to update to show the new location. Right now, no matter what the user does, it always says www.psykofil.org in the adress field.
I probably should mention that my options (freely translated from swedish) when I go to the configuration of my domain name at Loopia is the following:
DNS
Parking
Forwarding (the one I'm currently using)
Send to an external URL
(Unavailable because I don't have a web hotel with Loopia) Point to another domain in the account.
(Unavailable because I don't have a web hotel with Loopia) Own homefolder for webpage.
That's because your page is inside a <frameset>, so the address bar will never update.
You say "I've directed this domain to the index.html file referenced to above." It sounds like you've set up 'domain forwarding.' Framesets are often the 'trick' hosts use to keep the same URL - embedding the pages you're 'forwarding' to in a frameset. It's called "domain masking." See http://www.hostingmultipledomainnames.com/domainforwarding.htm for a description of how it works.
If you upload your actual html files to your site root, that should do the trick. If you're not sure how to do that and you're a new webmaster, you may want to be in touch with your web host's support. Otherwise, if you want to have that domain, but keep your files in your dropbox account, your options I believe get complicated (things like reverse proxies).
UPDATED:
Typically, when people create a website, they do three thing: register a domain, buy a web hosting account, and then associate their domain with their hosting account. You've done the first part, and have found a clever way of managing the second part, but you haven't done the third part.
The process is like this:
You register your domain. I.e., you pay $10-30 a year for the exclusive right to a given domain name. Registering the domain means that when people type 'http://mysite.com' into their browser, your domain will come up. However, it's just a placeholder - there isn't any real content there. All your files and images need to be uploaded to a server in order for people to see them.
You purchase a web hosting account. Or in your case, you upload your files to a publicly-accessible server, which has the advantage of being free. You then upload all your content.
This is the part you're missing. You now need to associate your domain name with your hosting account. This typically happens without your intervention when you purchase both your domain name and your web hosting account through one company.
However, if you acquire them separately, you need to do two things:
a. Log in to your domain registrar and point the domain name to your server for your web hosting account. This is a signal to the Internet - hey, when you type in the domain name 'http://ssss.com', go to this server.
b. Log in to your web hosting account and "park" the domain at your account. This may be hard to understand at first, but basically, just telling the Internet to go to this or that server when typing in your domain name isn't very useful.
If that's all we needed to do, I could just register http://my-amazon.com and point my domain to Amazon.com. Then people could surf Amazon.com as http://myamazon.com and I could get rich from selling this now incredibly popular domain.
But that doesn't work. In order for me to actually browse the web hosting account through my domain name, I need to "add" the domain name to my hosting account. Dropbox doesn't let you do that. It's a file-sharing system, which you've cleverly used as a web host. However, you'll never be able to log into Dropbox and park your domain there, because that's not what they do.
Summary: You can think of this process like a pass in basketball. You can throw the ball by sending the user to a server, but the server has to catch it. In order to catch the ball, the server needs to know it's coming.
Your domain registrar is 'faking' this process by adding one page to its own server, which links to "http://dl.dropbox.com/yourpage/etc/etc/Index.html". This way, your domain registrar doesn't have to worry about hosting all your content and the headaches of technical support and server space.
The downside is, you don't have a webhost that allows you to park a domain at the moment. The upside is you're saving about $60-100 per year (it might be more or less in Sweden), which is what a basic "shared" hosting account would cost.
You can decide if having distinct webpages (http://psykofil.org/contact.html" etc), is worth it for you, or whether you're fine for now with the very low-cost solution that isn't perfect but at least allows people to access your site. What you've come up with is actually pretty cool, but it does have some limitations.
Finally: If you do want to go ahead an buy server space so you can host your site, it will be less of a headache to buy it through Loopla, if the price and service are good. Typically, you are given the option when making the purchase of linking your account to your already-registered domain name. Then all you need to do is use an FTP program like Filezilla to upload your content to your account, and you're done.
It seems your host is "masking" the URL, meaning actual index.html page located at "www.psykofil.org" is in fact, loading your index page located via dropbox into an "iframe" , hence your main URL does not change to reflect the changes.
Solution: Upload your file to your main host and change the default index file that has iframes with the dropbox index file.
I believe it's because you're using frames. Were you to simply link to the other html page(i.e About page) then the address bar would update.