I am creating a way people can connect their Fb, Twitter and FS account to the account they create on my application. I wanna create a single table where i can store all the required stuff..
User(id, username, password, email)
Oauth (id, user_id, oauth_provider, ....... )
As for my Understanding
Facebook needs facebook id
Twitter needs id, token, secret
Foursquare requires email and consumer id.
Just wanted to confirm i am doing it right.. in constructing the Oauth Table.
I personally create a field named "setting_parameter" for the requirement's value because all of these API need different things. As you've said Facebook need App ID (plus Token), Twitter needs Consumer Key and consumer Secret..
All of this value I merge them all into one string with JSON-format. I don't put them each into the field because I think there won't be necessary for me to query this table for operations other than get their value. Beside, I need to implemented other APIs in the future. That's why I can't create special field, because I won't know what kind of value the new API will going to need next time. That's why I prefer to squished them into one string field.
The table of mine is like this
Oauth(id, name, setting_parameter, description,...)
Related
I want to have multiple logged accounts (with different auth providers Google,Apple, phone, email) in my app, so that the user can switch between accounts. To do that, I want to store the idToken and then use it to login without the need for the user to log in manually. I tried using this function:
FirebaseAuth.instance.signInWithCustomToken(token);
But it returns this message:
[firebase_auth/invalid-custom-token] The custom token format is incorrect. Please check the documentation.
PS. I'm getting the idToken wih this function
FirebaseAuth.instance.currentUser.getIdToken();
Image with the desired functionality
Thanks in advance!
I have tried storing the auth credentials but these have a short life time.
I expect to have tokens for different account, so I can switch this accounts.
I believe you may want to do something else rather than use the idTokens. What I would suggest is to check the providerId when a user logs in and originally links the accounts. Store this providerId locally and then in your database for profiles, have a collection by the userId with documents segmented by the providerId and just retrieve it the profile by the chosen providerId. Another option would be to allow one users to generate multiple profiles freely but limit it to maybe 5 different accounts, this would simplify the ux since they won't need to generate multiple accounts for the same functionality.
I am implementing an mobile app for android and iOS and I am using GAE with the datastore for persistance as the server side of my app. My app uses facebook login for user authentication. One of the key aspects of the app is that users can interact with each other through the app but I want to keep their actual facebook-id secret so that user cannot discover the facebook profile of another user through my app.
My original design for this was using MySQL and there I had a simple implementation of a users table with the table primary key, an auto-increment integer served as the user id for the app. So I could safely send the user id of other users to the client app, and this did not give away any information I did not want to give away. When a user logs in, the client app performs all the necessary facebook login procedures and sends the facebook access token to the server. The server would extract the facebook user information from this token chech if a user with this id already exists, if so use this user row, otherwise create a new one.
On an SQL database this works great since it is strongly consistent, and there is no way I will "miss" the fact that the user is already in the table. However now when I am using the eventual consistent datastore with the same idea, I ran into a problem where if a user logs in for the first time ever, an entry is added to the datastore, but then if the user logs in again shortly after the query I am performing to check if a "User" entity with the same facebook-id is already present this query sometimes still return no results. This leads to the same facebook id being assosiated with 2 different users of my app and this is obviously bad.
(I know this seems like an unlikely scenario, but I actually accidentally ran into it during development)
I thought of a few ways to mitigate this:
Instead of using the app user id as the entity key use the facebook id, this ensures consistency (since there is no index involved in the lookup now). This would imply I need to use the facebook id as the id for my app and this violates one of the design principles (the facebook id of other users will now leak to the client app).
Instead of relying on the datastore generated entity key id for the user, specify the id myself, by performing some sort of deterministic manipulation of the facebook user id, such as a hashing it or encrypting it. This way I can use the key to perform the lookup and no matter how many times the same user logs in their user id will be generated the same. But this seems like too heavy an approach to do correctly. If I hash it I will need to make sure to use a good hashing algorithm to prevent collisions. A good hash or encryption will output a long string as a user id, which is not too bad, but I would like to keep the user id as a simple long integer value if possible.
Accept the fact that this is eventually consistent, during a log in if we find more then one corresponding entity, delete them and stay with one. This is bad, because what if the user has already performed some operations that are stored on the previous entity? I will have to run through all the data for the multiple user entities from the same user and perform some sort of merging operation on them. This will also require me to run through other entities that store the user id and change them all.
Use memcache to store the user, this will probably make this scenario even more unlikely, but not eliminate it entirely. Memcache entries can be evicted prematurely, and in this case we are back to swaure one.
What is the best approach here? Is there something I am missing? Would really appropriate your input.
i need to map the same person's fbID between the old app(fb1.0) and new app(fb2.0)
Can i get the fbid list via a http request without accessToken??
That means i want to pull the fbid list with both my appkey & a user's fbid.
In order to match User IDs between different Apps, you need to use the Business Mapping API: https://developers.facebook.com/docs/apps/for-business
Consider reading the v2.2 changes of the changelog too:
A new token_for_business field makes it easier to identify the same person across multiple apps owned by the same business
Source: https://developers.facebook.com/docs/apps/changelog
For getting details (or just the ID) of a User, you always need an Access Token.
I am developing a iOS app, that will require the users to log in with third-party SNS account, like facebook, or twitter. However, I want to allocate "native" user id for each users for the benefits of future use.
For example, since each FB user is assigned an unique ID, say, 12345678, when this user log in with his/her FB account, I can get this FB id via FB's iOS api, then I can simply add a prefix "FB" to this id, stored a local text file with "FB12345678" as content in the i-device.
Then next time the app launches, it simply check the existence of this text file, and if not, pop out a view to require users to login, otherwise just use the content, like "FB12345678" as keyword to fetch data from my server.
Above is my own thinking. But I think there are some severe problems:
first, is it safe to store a string locally without encryption?
Second, if I use, say in the example, "FB12345678" to fetch data, is it safe to transmit via the Internet?
Chances are this " FB12345678" can be easily intercepted, and used to forge the identity of a user.
Lastly, if the user changes his/her FB password, I think my app should require the user to re-authenticate, but from the above strategy, obviously it does not work out.
So could anyone elaborate what is the most commonly used strategy, or algorithm, to enable thirdparty SNS account login? (like Instagram, Parse, etc.)
you can use the SDKs Provided by different Social Medias. It will maintain the session at your side. It is not proper to save userid on application side and other thing is that in almost all the medias you will require to send the access token and secret to request a data. and the Token Changes so its not good to save it. You can send it with your request and if it will be expired it will automatically ask you for the second time login.
please visit:
www.developers.facebook.com //for facebook
www.dev.twitter.com // for twitter
Try following links:
https://github.com/fhsjaagshs/FHSTwitterEngine
https://github.com/nov/fb_graph
hope this will help you.
With the new request id system request id are composed of 2 parts, the request id and the user id. The documentation
says you must delete the request id using the full id of the request but if the user has no accepted the application you can't have his id? Before when you accessed to the request you have a to field containing information about the user but now it's gone if the user haven't accepted the application?
So my question how access to the user id if he hasn't accepted the application? It clearly express that we need to delete the request but without the user id it can't be done).
I'm having the same issue in my own app. I've submitted a bug report since there doesn't seem to be any way of doing so (even though the Javascript SDK seems like it should work at first glance) https://developers.facebook.com/bugs/239476836116522