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
Related
Is there a way to implement a cross browser single sing on using CAS? I'm aware that this isn't a standard workflow and that SSO workflows work on a single browser using session cookies, but we have a specific need that would require to automatically sign in in another browser (e.g. MS Edge instead of Mozilla) via some kind of URL parameter. We would use a custom protocols on OS level to be able to open a link in a different browser.
One thing that slipped my mind that you could use service token (ST) which you get in CAS callback of app1 and use it to open another application (app2) in a different browser. I guess you would also have to fake a client ID, i.e. use the one that retrieved a ST.
And of course, ST would need to be valid for a long time, i.e. it shouldn't quickly expire.
Is there some kind by-the-book alternative for this in CAS?
Thanks a lot!
Igor
CAS provides support for token-based authentication on top of JWTs, where an authentication request can be granted an SSO session based on a form of credentials that are JWTs. CAS expects a token parameter (or request header) to be passed along to the /login endpoint as the credential. The parameter value must of course be a JWT. You can create this JWT and pass it to any browser, and you'll get a session back. See this for more info.
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
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.
I try to call vimeo API from browser's javascript. When I try to get access token (POST https://api.vimeo.com/oauth/access_token) I get 405 response and CORS error.
Is it possible to make API calls from browser?
Generating access tokens are not currently supported in the browser. Eventually they will be in a very specific circumstance.
For now you need to generate your access token serverside and share it with the client. Be careful though, these tokens do not have an expiration so your clients can take them and use them forever.
We will be fleshing out support for browser-based API calls in the future, but it's still a while out.
I'm building an files upload API.
Basically, the user will have to POST the files with his/her api_key + signature to my web service. Then my web service replies back with a JSON response. I'm wondering how can this process work asynchronously?
Assuming that the user POST the request in a form setting the target to an iframe. The JSON response will be sent back to the user on his/her iframe with content type set as "text/html". It is set as "text/html" instead of "application/json" because I want to avoid having a "pre" tag injected by the browser around the JSON response. Anyway, how does the user read that JSON response if the iframe and the parent window have different domain? There is going to be a cross domain policy issue.
Dynamically create "script" tag plus JSONP won't work in this case because I need to POST in order to upload. JSONP only works with GET requests.
Take a look at the 'Upload' example here. It uses Cross Domain messaging to pass the message back to the uploading page, and uses easyXDM to support all browsers.
This post explains how it all works!
Because of Same Origin Policy, browsers wont allow JavaScript in the main frame reading/accessing whatever content in iframe from another domain. In this case, the users will have to use easyXDM or create their own proxy -- by proxy here i mean users will have to write some code on their backend that can communicate with your API such that a post request will go directly to your server, and a get response will get from their own proxy.