I have a question about which access token should be used for publishing news feed to user's wall via PHP SDK.
Basically, there is a delay, let say 7 days, between user connected to the app and the news feed get published. My understanding is we can store the 60-day long-lived token into database first and then make use of it 7 days later.
However, the article here suggested that it is possible to use the app token (with no expiration time) to publish news need.
So, my questions are
Which token should I use under the current scenario?
Which one will be safer to use?
Is there any risk of using either long-lived token or app token?
Thank you very much!
Related
I was asked by a potential client if I can have my software interact with Esri/ArcGIS Online.
Use case: users is logged into SomeRandomSoftwareApp and is looking at a Widget, this Widget includes an Esri asset id, the user clicks a link that passes that ID to Esri/ArcGIS Online and behind the scenes the user is logged into Esri and they see the data associated with the Esri/ArcGIS Online.
Thanks, Keith
If I understand correctly, you have two options for this: API Keys or Application Credentials.
The first one, is a permanent token generated by the owner of the data that will allow the application easy access to it. This is still in beta, and it was not ready for use the last time I check some time ago.
The second one, the owner of the data will generate credentials for your application. With this credentials you will have to request a token each time you want to access the data, all this via OAuth 2.0.
Check the docs for more details ArcGIS Services - Security
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 have a general comprehension question about OAuth access token retrieval for a Google Chrome Extension.
I have a popup HTML window in the browser that uses Jquery to request data from the server (a LAMP stack on AWS). The data is presented by PHP scripts which access a MySQL database. All very basic stuff.
I now want to implement a push messaging system using Google Cloud Messaging to alert users of new content that they can check. However I don't really understand where I should request the access token and how to listen for the response. I figure it should be in the PHP scripts but all the Google documentation that I've read states the user has to be present in order to allow access to push messaging. That tells me I should put it in the JavaScript but I feel this is a bad idea because every user could potentially request an access token when I think I only need one every 3000 seconds or so. If my app was completely implemented in PHP I'm sure this would be possible and now I'm worried that splitting it up like this leaves push messaging out of the question. Am I missing a crucial detail or just out of luck?
If the data access you need isn't user-specific, then you're right, there's no good reason to get a separate token for each user. Check out https://developers.google.com/accounts/cookbook/roles/Apps which discusses some options.
I got the Access Token using Box Api but it is expiring in 1 hour.
What I want here is,
Either I need non expiring access token or get the access token by passing my Box User Id and Password to API.
If above things are possible let me know the way.
Thanks in advance..
You've got what is called a Bearer Token and a Refresh Token. The Bearer token is good for an hour, and the Refresh token is good for 60 days. The Refresh token can be traded in for another pair of tokens, which resets both clocks at the time you do the refresh.
Box doesn't have tokens that you can get via a username-password grant in OAuth2, because that inherently doesn't work for enterprise customers that need to do SSO through their ActiveDirectory / Okta / Ping / 2-factor / SecureID signin flows.
What you probably want is an SDK that handles the refreshing of the token for you. Most users won't ever have to logon a second time, unless they go on vacation for a few weeks. Box has already released several SDKs, all on github with open-source licenses. Most of them take care of refreshing the token for you automatically.
We've also added some enhancements recently (early 2014) to help multi-server implementations work more smoothly with the refresh-token flow, including allowing you to use the old refresh token to get the new token multiple times in a narrow time-window. That helps with both multi-threaded environments trying to get new tokens across a number of threads (or servers). It also helps with the case where you have a network interruption and you don't actually get the new token-pair back from your initial refresh call.
I have a simple facebook site feed on my website, it allows no interaction by visitors to my site. It is literally a set of json dumped to a userlist.
The issue I am having is that the access token expires every 1-2 hours and the feed dies...
I need to automate the refreshing of a token or get a non expiring token. What is the best route for me to take.
I want to ensure that security is as high as possible.
many thanks
You can get the extended token, red this : Extended Access Tokens
This token expires in 2 months so no need to refresh this again and again.
And if you want to offline access on behalf of this user, you can use this and refresh it before its getting expired.