Vimeo allows users (pro only feature?) to set the video to be "whitelisted": they will only play when embedded in certain website. Technically, it is implemented by checking the referer header.
I was wondering if it's possible to get info of such info via API (when referer whitelist is known).
Keep in mind I'm talking about video uploaded by others, not account which API is authorized in.
This data is not available in the API.
Related
I want to be able to offer a RT transcription in my browser app using AWS transcribe. I see there is the TranscribeStreamingClient which can have credentials for AWS which are optional - I assume these credentials are required for access to the s3 bucket?
What I want to know is how to setup auth in my app so that I can make sure my users dont go overboard with the amount of minutes they transcribed?
For example:
I would be expecting to generate a pre-signed url that expires in X seconds/minutes on my Backend that I can pass to the web client which it then uses to handle the rest of the communication (similar like S3).
However I don't see such an option and the only solution that I keep circling back to is that I would need to be feeding the audio packets from to my backend which then handles all the auth and just forwards it to the service via the streaming client there. This would be okay but the documentation says that the TranscribeStreamingClient should be compatible for browser integrations. What am I missing?
I have a media file linked to a URL (like https://songexample.mp3 (not the real url)). I want my app to play that audio, using something like
audio = new Audio('https://songexample.mp3')
audio.play()
But I would like to make it so that users cannot view the underlying URL itself, and also so that only logged in users can play the URL.
I am wondering if I can use API Gateway for this purpose. Through tutorials like this one, it seems clear that you can link API Gateway to Cognito, so that only logged in Cognito users can access the API Gateway endpoint.
But, this example and the others I have seen assume you are using a REST endpoint, with a specific parameter (like id at the end), to get back information. In my case, the URL will not return text-based information, but will actually play media.
API Gateway seems to expect that the end of the URL will provide data for a {proxy} parameter--but my URL must end in mp3. Not surprisingly, when I've tried I've just gotten back 404 messages so far.
Is it possible to use API Gateway to limit access to this kind of URL?
I am trying to send a PATCH request to the Vimeo API in order to start uploading the video based on the documentation.
I am using Postman. I've read {upload.upload_link} field, set the required headers but I still can't hit the API.
Does anyone know what could be the problem?
Try making that PATCH request again, but without the Authorization or Host headers, as they are not required for that upload endpoint:
https://developer.vimeo.com/api/upload/videos#resumable-approach-step-2
"Instead of using cookies for authorization, server operators might
wish to consider entangling designation and authorization by treating
URLs as capabilities. Instead of storing secrets in cookies, this
approach stores secrets in URLs, requiring the remote entity to
supply the secret itself. Although this approach is not a panacea,
judicious application of these principles can lead to more robust
security." A. Barth
https://www.rfc-editor.org/rfc/rfc6265
What is meant by storing secrets in URLs? How would this be done in practice?
One technique that I believe fits this description is requiring clients to request URLs that are signed with HMAC. Amazon Web Services offers this technique for some operations, and I have seen it implemented in internal APIs of web companies as well. It would be possible to sign URLs server side with this or a similar technique and deliver them securely to the client (over HTTPS) embedded in HTML or in responses to XMLHttpRequests against an API.
As an alternative to session cookies, I'm not sure what advantage such a technique would offer. However, in some situations, it is convenient or often the best way to solve a problem. For example, I've used similar techniques when:
Cross Domain
You need to give the browser access to a URL that is on another domain, so cookies are not useful, and you have the capability to sign a URL server side to give access, either on a redirect or with a long enough expiration that the browser has time to load the URL.
Examples: Downloading files from S3. Progressive playback of video from CloudFront.
Closed Source Limitations
You can't control what the browser or other client is sending, aside from the URL, because you are working with a closed source plugin of some kind and can't change its behavior. Again you sign the URL server side so that all the client has to do is GET the URL.
Examples: Loading video captioning and/or sprite files via WEBVTT, into a closed-source Flash video player. Sending a payload along with a federated single sign-on callback URL, when you need to ensure that the payload can't be changed in transit.
Credential-less Task Worker
You are sending a URL to something other than a browser, and that something needs to access the resource at that URL, and on top of that you don't want to give it actual credentials.
Example: You are running a queue consumer or task-based worker daemon or maybe an AWS Lambda function, which needs to download a file, process it, and send an email. Simply pre-sign all the URLs it will use, with a reasonable expiration, so that it can perform all the requests it needs to without any additional credentials.
I have an API that I want to provide public access to, but I want to be able to limit access.
I've been thinking about Twitter's model:
Twitter allows developers to access the data using an api key (I think).
Twitter must also access the data from their website to allow you to tweet / search.
So Twitter must be able to stop developers from impersonating twitter and basically using their api key.
How do they do it? And is there a better way?
Twitter doesn't use their REST API to power their website, they query their database directly. Therefore, there is no API key to steal. You can read about the difference between Twitter's API and Website database queries (circa 2009) here.
The basic techniques Twitter uses to rate-limit their API will probably be the ones you would want to consider, too:
Unauthenticated calls are permitted [fewer] requests per hour.
Unauthenticated calls are measured against the public facing IP of the
server or device making the request.
OAuth calls are permitted [more]
requests per hour and are measured against the oauth_token used in the
request.
The mechanisms to implement that depend on your server platform (you should update your original post with that), but you can learn about OAuth (the second technique above) on their website.