So I'm making an app where I use foursquare API to get closest venues. I'm also thinking about using the features that require the user to authenticate, like check in endpoint. But as I have explored the foursquare authentication, it seems like that my users would have to create foursquare account to use my app.
My problem with this is that it feels like I'm giving too big part of my app (all the user details) to foursquare's side. Like if I want to create features in my app that don't require foursquare account, isn't the linkage to foursquare's stuff restricting my ability to grow my app (as my users are basically all foursquare's users.)
So is there a way to create my own user database while using the foursquare's features? Or is this even a thing to take into account? Will it cause me problems in the future?
The checkin endpoint requires user authentication because a user is checking into a venue. This is key feature of foursquare. The user has to be a foursquare user because there'd be no other way for foursquare to track them and stats, and comments, etc.
I think what you want to do is create your own app that allows someone to do things similar to Swarm or some of the venue features in Foursquare. You need to create your own database of user information and track everything yourself. If a person wants to use any of foursquare features they need to be a foursquare user. Anything your app keeps track of wont be a part of the foursquare network. One could not checkin with your app and have it show up in foursquare, if you keep things separate.
If you decide to mix and match just remember there are time limits on data caching that foursquare would like you to adhere to.
As for future problems, read the Terms Of Service for the API carefully, and if your app seems like a clone of either Swarm or FourSquare, and you're not using their users, they might ask you to cease and desist
Related
We are working on a system which retrieves data from customers' Shopify shops and provides some services based on this data. In order to make it as convenient as possible for an end-user we would like to update this data on a daily\weekly\monthly basis.
For now we only came up with a solution of implementing unlisted app, prompt a user to provide all necessary permissions for the app to access their shops and fetch the data. But the token we get doesn't seem to be valid for a long time and we probably won't be able to reuse it a day later.
We appreciate it if you can share any success cases of implementing this kind of approach.
You provide an App to the merchant they can install using oAuth. When the merchant is prompted to approve the App, Shopify will then provide your App with a long-lived access token you can use as much as you want, for as long as you want. I use a custom App from my Partner App dashboard to create these kinds of one-off Apps. It is superior to the one where the merchant has to tick off scopes and permissions IMO.
There are two kinds of token you can ask for and receive. One is considered for offline access, or long-lived. It works for everything. It is for webhooks as an example, or other access where no person is involved. But, there is also, online access tokens! Say a person clicks into the App from Shopify to do some work. You can request an online token for them to do their thing, and that token is only good for say 24 hours.
So you have options!
Recently google has added multiple user support to the assistant so how would use the API to identify the person by voice?
It depends what you mean by "identify the person".
There is no way for an Action to get the raw audio, so there is no way for it to do voice printing or anything along those lines.
Although each voice has to be reported against a Google User ID, you do not have direct access to that user ID.
What developers do have access to is a UID that is sent along with each request to your fulfillment server. This UID is consistent across requests, although it can be reset by a user (for example, if they reset their Google Home). You can think of this the same way you think of an HTTP cookie - you can track the UID and, if you see it again, have reasonable assurance it is the same user that accessed it last time. This breaks down, however, for the "default" account on Google Home, since anybody who doesn't have an account will map to this user.
Beyond this, you can also use Account Linking to connect a Google Account consistently to an account in your own system. If you have sufficient authentication in place, or are using one from Google or Facebook for example, this can act as an identity.
There isn't an API for developers to identify users by voice.
I've looked briefly through Spotify's API documentation to try and see what exactly can be done with the API. I'm trying to do some data analysis on Spotify data, specifically on user listens / user playlists. However, as far as I can tell, the only way to uncover that information is through OAuth, and each user whose play information I desire would need to explicitly grant permission to my app to use their information. Since I am not building a user-facing app and am interested in doing mass analysis on many users at once, I don't think this would work for my purposes.
My question - is there any way to return multiple users' listening habits through a script that pulls data from Spotify using its API? Or is that possible strictly by way of an application that one user at a time gives authentication to when they load an app that uses this API?
is there any way to return multiple users' listening habits through a script that pulls data from Spotify using its API?
Spotify doesn't expose users' listening habits unless they authorized the app requesting it (I think this is what you meant when you said "through OAuth"). There's pretty big privacy reasons for not exposing users' data to the world.
We would like to develop a survey in which consenting participants would have to give us access to their list of checkins on Foursquare. Currently, we do so via a Foursquare app, but I do not seem to find a way to specify which permissions our application needs.
Whenever a user is asked to grant access to our app, he is informed that we will be able to post checkins on his behalf and do a bunch of other things. This will raise concerns and will likely lower the number of willing participants.
The question would be whether there is a way to restrict the permissions of our app to what we actually need, i.e. the full list of checkins.
As an alternative, we are considering befriending the user from a special account instead. However, does friendship guarantee that we can see all of his checkins?
The Foursquare API currently doesn't support scoped permissions (e.g., seeing check-ins only). You will have to make it clear to your users that you won't post to their accounts.
The only way to see a person's entire history of check-ins is if you have an access token for them, so unfortunately the befriending method won't work.
If users link their foursquare account to my site, via oauth2, when I pull a venue from the foursquare API would I be able to test if the current user is the same user who verified the venue (assuming the venue is verified)?
Or... is it possible to use the foursquare API to know who verified a venue?
I'm trying to build a service which venue owners/managers can use to help their business. However, I'll need a way to verify they are the owners/managers of the venue. I believe a very effective way to do this would be to force them to link their foursquare account, and then test if their account was the one that verified the venue.
If that's not possible, what's the standard way this is performed?
Instead of testing if a venue is managed by the current OAuth'd user, would it make more sense to get all of the venues that the current user manages? You can do that through our venues/managed endpoint.
Also in general, your approach of requiring the user to OAuth is correct and pretty standard for these style of apps. Our info on our merchant platform should be able to help you out.