I'm trying to identify a user by storing the Apple Music User Token on a database. Is this token the same for an Apple Music user over multiple authentications?
I seem to have run into a hiccup here - over the course of the development (me being the only developer), I noticed four different user tokens registered on the database, despite only using one login. I want to double check if the User Token is in fact not the same over multiple authentications before I move to a different method of identification. Also, is there any other way of identifying a user similar to using the Apple Music User Token, as I'm trying to avoid using a login.
Related
I have a Slack App (source code) where I want to send reminders to channels where a certain piece of text has been mentioned the most on a schedule. It works, but there's a limitation:
The search.messsages API method only supports user tokens. I want this to run in the background, without interaction. Approaches that have come to mind:
Store my personal user token
Con: Would allow others with access to the token to be able to see my private messages
Create a fake user whose only purpose is that user token
Con: Have to pay for that fake user indefinitely, manage shared credentials, etc.
Any other ideas?
Here is what you can do:
Switch on distribution of the Slack app.
Have the admin, or an existing user on the Slack channel install the app. During the time of installation, you can ask for permissions with user token and search:read scope.
Now you can make all the searches using this user's token. You'll need to plan for the scenario where this user is deleted from the Slack workspace, your user token will stop working.
I don't think there is a way to control it from searching for your personal messages. Search functionality is dependent on the user token.
I'm currently trying to build an 'account switching' feature for my iOS App that uses Google Sign-In (with YouTube scopes to get YouTube channel data) & Firebase Authentication.
At the moment, if users want to switch accounts, they have to log out and log back in with another Google account, which is not great from a UX perspective.
My end goal is to allow users to log in with several channels and then choose the YouTube channel they want to see data for, from inside the app, without logging out and back in.
Is there a way to maintain several OAuth sessions alive to let user easily switch between accounts?
I have thought of storing the user's access token locally in a dictionary that would map channel ids with the relevant token but I'm not sure if that will be enough to maintain the state properly or if it will lead to a bunch of bugs.
Any ideas or suggestions are more than welcome.
Thanks.
With Firebase Authentication, there can only be one signed in user at a time. The SDK can't manage multiple signins at once. The prior user needs to be signed out at the time a new signin is processed.
I am building a backend for ios apps, that support login in different networks.
Once the user login in to the network the client tells the news to the backend, and this could offer a list of worlds that the user might play, or even delete old worlds.
One way to steal another person's world is by saying that you are his social network id.
To solve that with facebook, we force the client to send us the fb_token, a token provided from facebook to the client, that we use in the backend to ask facebook if that specific user is the one that he told us to be.
If apple doesn't provide a way to validate this I understand that if an iOS app wants to use game center, it is directly forcing the app developer to also use iCloud because apple can validate the user credentials.
Did apple provide any way to validate user credentials?
The client on iOS can retrieve info about the currently logged in player in GameCenter, which has nothing to do with iCloud.
If you want to use iCloud to authenticate, you might have a different player than the one you wanted.
I think the solution is for the client to retrieve the player info in GameCenter, and send it to your server in an encrypted fashion (say HTTPS), including a timestamp and possibly other dynamic information. This way you'll know that the user info is being sent from the client app itself and there is no man-in-the-middle. That's really the issue that you are struggling with: how to ensure that client-server communication is secure.
The app should be uploading videos from iOS devices directly to our own YouTube account (not user's account).
In every scenario I came across you need an Access Token that you can get only from user logging in through OAuth2 (window popping up). Obviously, we can't give everyone username and password from company account. I was imagining using some key that uniquely identifies the app and YouTube user account to use.
Any solution / pointer? Thanks.
I ended up using deprecated Client Login. We still need to figure where to store passwords (either in the client app, or fetch them from backend every time), but that's already a huge progress.
Unfortunately, Google says Client Login will be removed in 2015. We can just hope they'll come up with non-interactive auth method requiring no user interaction by then.
I'm working on my first rails app and am trying to make it so that Users can create a joint Playlist and then play that playlist. I planned on using Hallon/Libspotify to create the playlist but am running into a problem because Spotify requires users to login with FB.
I currently have it set so that Users login to the site using Facebook but I don't think the information FB gives me is enough to auto log the User into Spotify. Any suggestions on how to implement this functionality would be super appreciated!
You can't use a Facebook auth token with libspotify.
libspotify requires a username and password pair, whether it's a Spotify name/password or a Facebook name/password. Once you log in with libspotify, you'll be given a separate login auth token for storing and future logins.
It's important to abide by the libspotify ToS when writing your app, as it's easy to break them when writing a web app. The two most important are:
Never store a username/password yourself. Only ever store the token you get (it's safe to store unencrypted).
Never log in on behalf of the user when they're not using your application.