On Vimeo (using their API), is it possible to generate private links that automatically expire? If not, what would be a good workflow to approximate this function, based on the API's limitations?
Basically, we would like to provide subscribers to our website limited time access to our videos. We would embed the player links in a private area of the site.
We wouldn't want users to have the ability to copy the link code and keep accessing the videos after their access has expired. Also, in the case of multiple users wanting access to the same video, we wouldn't want any updates to the privacy settings of a video to interfere with previous user access granted (that has not yet expired).
The Vimeo API can only toggle a video's privacy settings, the API cannot grant playback to a viewer outside of the privacy settings available.
For example, the API can be used to set a video as password-protected and set the video's password, however the API cannot be used to authenticate and bypass password protection and allow playback.
You could deal with this by providing a redirect from your own site and have the redirect expire. That would provide the functionality you’re looking for, but it’s also very easy to circumvent. It depends how strict/hard you want to make the expiry.
Related
I am about to implement a reception screen view of some data my product holds. This data is not extremely sensitive, but enough so that my customers do not want it just out there on the internet for all to see.
The concept is a smart tv with a built in web browser that displays a webpage hosted by my application. My application requires authentication for all other interaction, but the smart tv does not support authentication. So I would like to secure the page somehow, so it isn't just available for all to see.
The only options I see are:
Security by obscurity. I would really like to avoid this one.
IP Whitelisting. This I could do, but not all my clients have a static IP.
Enter credentials on screen. This is not really feasible and the credentials are lost on reboot. So we cannot do this.
Are there other options I just don't know about.
For límited input devices like TVs where is not easy enter credentials there are some Open Source options like CPA (developed by EBU for Hbbtv Use Cases) than can work for you and you can control the e2e
CPA
Reference Implementation
The autenticacion token can be stored into your SmartTV app until its expiration or client's logout, etc.
There is also
After some research I found that the best option is the OAuth 2.0 Device Authorization Flow.
The gives the user an experience like the one used when setting up Google Chromecast or AppleTV.
https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow
I'm enjoying developing cross-browser web extensions, the main target being Chrome, so much that I started to think to develop one for my company. I find a chrome extension quite a cheap and efficient way to deploy internal apps. The main purpose is to host a couple of dynamic dashboards that fetch data from various APIs by using cross-domain ajax in background scripts. I finalized the app and I was also able to implement the authentication via chrome.identity and Azure AD.
However, I am struggling to find a safe way to customise the content.
I mean, when the extension is installed it requires to login to azure via the chrome.identity flow. Then I get a token that I use to query ms graph and get the user ID, name, email and basic info.
Until I get this information I want the browser action (popup) to be unavailable to the user as well as any other extension pages. After a successful login I would like to show the content on the pop up and to let the user access the pages, but here I want to customize the experience.
I know how to use the user id retrieved from the api call to customize the extension, but I think it is not safe because all the code is in the client.
If I code something like
if (user === logged) show something
it will be damn easy for a malicious user to look at the code and bypass it, or even to impersonate another user. And chrome extension cannot be obfuscated.
Any help?
Thanks
I am trying to authenticate a user inside a desktop application using the web api. I am not using a browser, I am using straight up GET and PUSH calls to the endpoints of the Spotify servers. Immediately I ran into some problems. It appears that upon the initial GET command to "accounts.spotify.com", the returned response includes HTML with a javascript function that runs and is responsible for dynamically generating HTML that you see on the initial login page. If you look at the Javascript function, it is clear that this is what is going on, however, you can also see this code is obfuscated and not meant to be used by us, the developers! (Link to Javascript code here for reference: Javascript function)
So my question is, while I can probably reverse engineer the code to get this working, would this be against the Spotify developer TOS?
Thanks!
Spotify's authentication happens through oauth, and a big part of user authentication as per the oauth rfc is where the user delegates permissions to your app to carry out API calls that affect their account, or return information about them. That's the web page you're seeing - it must be presented to your users so that they can delegate permissions so that Spotify can give your app an access token. It doesn't necessarily need to happen in a browser - it can happen in a web view inside your desktop application - but it does need to be loaded over https, and your application must not alter or reverse engineer the Spotify permissions delegations page.
As you correctly guessed, reverse engineering any Spotify APIs is against terms of service.
For more information on authorization on the Spotify platform, I'd recommend having a look at this guide.
Hope that helps! Please ping me if you have any more questions.
Hugh
Spotify Developer Support
I am trying to make a webpage that can display information about documents on my google drive. For example I would like to display the titles of all my google documents on a webpage. I don't want the user to have to be logged into a google account, and I don't want to have to authorize anything (or the user to authorize anything). I just want the user to be able to see what I display - in a read only format - when they navigate to the page. The user will have no chance to edit or upload or delete anything, they can just view the info I display.
Is there a way to get files from google drive (via the API or any other way) possibly without using oauth 2.0? I've looked through the api docs and even coded up the sample apps, but all of them have a step that says, "Go to this URL, click Allow, enter the code" then you get access. These steps shouldn't be necessary. I just want to download the file and be able to manipulate it (either in memory or as a stream) then display something about it.
Also, I may misunderstand how OAuth 2.0 works so if that seems like the case, any helpful information would be much appreciated. Thank you.
You don't need to authenticate your visitors into Google, but need to authenticate yourself, so your web app can retrieve data from your personal Drive.
Get an access token and refresh token for yourself, store them and autenticate your requests. If you're using one of our client libraries, most of them refresh the access tokens once they are expired. See Using OAuth 2.0 for Web Server Applications for more details and OAuth 2.0 Playground helps you to understand how to get these tokens.
I have a Youtube video set to private so nobody can watch it via Youtube or the embedded player. However I do want people be to be able to watch it on my website. The goal is to make the video available exclusively on my website for a while before I open it to the world. I was thinking to login to my Youtube account seemlessly using Youtube's API and log out after the video's finished but that doesn't make security sense. What's your take on that?
I agree with your intuition. Making the private sharing secure seems tricky at best. Although the Data API has procedural authentication options, I don't think Player API has that facility. Furthermore even if it did, it's hard to see how it might work without exposing your password.
Your best bet is probably to directly host the video on your website. You would use your website's authentication for restricting access limited release video. Then when your ready for the public release you can either switch to YouTube hosting or relax the authentication of your self hosting. The Video for Everybody site has examples of several options for self hosting of videos.