I created a very simple application to pull and display videos on a client site from an album. Everything was set up and humming along fine when it suddenly stopped working. After tracking down the problem, it turned out that the OAuth Token and Secret changed without warning last week.
Is this something that will happen periodically? Has anyone else experienced this?
Vimeo's OAuth tokens will only change if granted via XAuth (username and password auth). If this is how you generated the token, it means the authenticated user changed their password.
If this is not the case, user tokens are additionally revoked any time Vimeo forces a password reset. If you want to find out the exact cause you can contact vimeo directly at https://vimeo.com/help/contact
Related
Users of my web app have requested an "offline mode" that stores their work on the hard drive while an Internet connection is not available. They could be offline for anywhere from a few minutes to multiple weeks, so in order to prevent loss of their work, I'll need to be able to persist the data, even when under storage pressure (using IndexedDB without the proper permissions could result in data loss).
I read on Google Developers that the asynchronous navigator.storage.persist() method can be used to request the user's permission to store files, but that doesn't work on Chrome - the promise always returns false without prompting the user.
Then I read here that Chrome may decide not to show a permissions popout, but instead grant or deny persistent storage permission based on a precalculated decision. This appears to be based on the following:
The site is bookmarked (and the user has 5 or less bookmarks)
The site has high site engagement
The site has been added to home screen
The site has push notifications enabled
If any of the above are true, the permission is already granted, and if not it's automatically rejected. This means that in Chrome, there's no difference between navigator.storage.persist() and navigator.storage.persisted(), even though the first is supposed to be a permissions request and the second is supposed to be a permissions check.
I've already built in-app UI for requesting persistent storage permissions, so all I need is a sure-fire way to get the permissions popout to show in Chrome so the user can grant or deny that permission. Since I can't control the first three conditions, or reasonably ask the user to satisfy them, it seems like my only option is to ask for permission to show push notifications, which is unfortunate because that is not the permission I need and I have no interest in showing push notifications. A permissions request like that would likely confuse users.
Is there a more clear, user-friendly way to get permission to use persistent storage in Chrome?
If any of the above are true, the permission is already granted, and if not it's automatically rejected.
This is incorrect; the permission must still be requested. Until it is requested/granted the origin will still be treated as "best effort". The site must explicitly request the permission. You can observe this by calling persisted() prior to calling persist() on a site that has never requested the permission.
all I need is a sure-fire way to get the permissions popout to show in Chrome so the user can grant or deny that permission
Chrome does not have a permission popup for this permission, so there is no such way.
The preferred model is to not offer guarantees about offline capability until the permission is granted; that is, request the permission and only show any sort of "your data is absolutely definitely available offline" assurance once it has been granted.
As mentioned by Joshua Chrome does not have a permission popup for this permission.
What I did was manually enabled the push notification in the site settings for my website.
This was enough for Chrome to grant my website persistence storage permission.
I recently started getting a 'Permission Denied' response from our vimeo album. Everything was working correctly and nothing has changed on the application. Also, I checked and it appears no permissions have changed on the album or included videos in terms of permissions. However, we did change the servers we're hosting our main site on, which resulted in a change of IP addresses but the site URL did not change.
Is it possible that the IP change somehow messed up the request we make to vimeo? I looked in the admin settings on vimeo and didn't see anywhere we needed to specify IP addresses.
Basically, we're doing the following:
$vimeo = new phpVimeo(CONSUMER_KEY, CONSUMER_SECRET);
$vimeo->setToken(OAUTH_TOKEN,OAUTH_TOKEN_SECRET);
// **** GET THE VID DATA FROM VIMEO **** //
$result = $vimeo->call('vimeo.albums.getVideos', array('album_id' => xxxxxxxx,full_response => '1'));
$videos = $result->videos->video;
And, as I said, this was working great for a while. Any ideas on what may have happened? Thanks!
IP address should be irrelevant to the API.
My guess is that your account was part of the Adobe email breach (you should have received an email about this). Vimeo reset some tokens relating to the Adobe email breach to ensure account security.
If you were not part of the breach, you can contact Vimeo directly via https://vimeo.com/help/contact to learn more.
If I specify access_type=offline in the auth url and a user attempts to auth a second time I get a box that says it is asking for offline access.
I would have expected it to be already authorised and so not require additional permissions
Any ideas?
Edit:
A bit more info. The first time around it makes no mention to the user of needing offline access. I would have thought the offline permission to be mentioned in the original auth anyway.
Edit 2:
Some more info on my use case. It is possible in our system for a person to have two accounts but then use the same google drive account. This means that we have no way of knowing that user has already authorized with google and so have to present the authorization again for the second user.
The first time around (for user 1) you are told that the app is asking for :
View and manage Google Drive files that you have opened or created
with this app
View and manage the files and documents in your Google
Drive
The second time around (for user 2) you are told the app is asking to:
Have offline access
This seems wrong to me.
As an aside:
The whole "have offline access" statement is very confusing for a user and also quite misleading. Most people assume this means the app can read the contents of your pc. In fact it means that the app can authenticate with your account with out you being there (i.e. using a refresh token).
I was following the steps from box.net document
http://developers.box.com/get-started/#authenticating
I can get a ticket as it said first.
Then I use that ticket at following url https://www.box.com/api/1.0/auth/{your ticket}
in a browser, it works as it says. the browser will direct the user to box login page.
In that login page if I input username/password for login.
I can get the auth_token as the document says.
The problem is while I didn't choose username/password for login but use google openid to login an box account.
I will not able to get that auth_token as the document says. the returning response with following status:
not_logged_in
I want to know if this is a bug or I not correctly using the API to get that auth_token.
As many of box user now are using google openid as primely login choice this seems an common use case need be supported.
If anyone know the answer would be very appreciated.
Thanks
If a non-OpenID user is able to authenticate through the Box API's standard authentication process, then your code is fine. We have had reports of issues for our Single Signon issues, so this is likely a bug on our end.
Just make sure your app can authenticate users who have Box passwords. When we resolve these SSO issues, OpenID users will be able to connect your app without any changes on your end.
I'm busy to enable login stuff via facebook oauth on my website, but the only thing I want to get is the email of the user.
I saw in dev docs the 'scope=email' but, it seem's mandatory for the user to allow access to anything about him.
is there's a way to ask him to grant access only on his email ?
No. The bare minimum that your app will request from the user is his Basic Information, followed by your extended permissions (in your case, his email address).
nope. email is a so called extended permission. so you have to get the basic set of data of the user. (like: name, fbid, gender, locale).