Is there a way to stop accounts.setAccountInfo from deleting an email if it is the last standing login ID?
Currently if I have 2 verified emails both loginIds and issue 2 requests removing one email at a time (I know I can pass a comma separated list) I end up with an account that can't login anymore as no login Id is left.
Both return 200 ok and no error code.
I've looked for an etag implementation so I can at least force some sort of an optimistic lock but couldn't find support for it.
Any ideas?
This is by design, as in the case a user's email(s) were compromised, there needs to be a way to disable login of the account until the user can have their information updated via a customer service representative. There is no out-of-the-box way for an end-user to use this particular parameter, so, unless a currently logged in user is manually calling the method from the JS console, there is no way for this scenario to accidentally happen.
From the server-side, if you are worried about a specific application from calling this method and require restricting a specific app from accessing this particular API you can assign the application key to a permissions group with restricted permissions. ref:https://developers.gigya.com/display/GD/Console+Administration#ConsoleAdministration-PermissionGroups
If you think this behavior should change, please open a ticket from your Gigya/CDC account dashboard for investigation.
Related
I'm using omniauth to authenticate a user via Google. When the user logs in via Google, I check if an account already exists with the same email (if it does, I reject sign in).
When I create the new User model, I give it the name, email, and the URL of the user's 'image'. I am not sure how to dynamically update the information in my database when the user changes their settings on Google, including the image_url when they change their profile image.
A good example of this scenario is this Stack Overflow; I signed up to SO with Google. Having changed my profile image (recently), I was surprised to find that my old Google image remains attached to my SO profile. Maybe it takes time for Google to change the old URL to represent the new image. I have noticed that some parts of Google use my new image, and other parts continue to use my old. Of course, this question doesn't have much to do with Google's profile image mechanism, I just think this is a perfect example.
My questions are:
Should I want to do this, or should I instead provide the user the ability to change their details through my site, completely ignoring what happens to their Google profile?
If I should do this, what is the best way? Checking on every login isn't ideal as the user might not log out for days or even weeks.
Should I be storing the Google auth token? Currently, I'm not as I don't need to make any Google API calls -- I only use OAuth for the 'uid' to ensure it's the same account logging in (the email isn't used at all).
I don't think the answer will be "don't store user info, query Google instead", so I'm not really sure what best practice is in this scenario. A brief walkthrough on proper procedure would be very helpful.
Normally, oauth applications will use the endpoint /me.json as part of the login process: After the user is signed in, the app uses that fresh token to query their profile info right away and update data. In your case, I understand you ignore when email already exists. You should probably add a new step there, to update your local record if it already exists instead of purely ignoring it.
In other words, your app wont be automatically notified if users change their profile pictures. But you can always use their log in action to fetch the latest image (or use their token in a background job that runs every n periods of time using something like cron + whenever, assuming the oauth scope authorizes offline access)
*Apologies in advance for the long background but I think it is necessary and helpful to other devs once this is answered.
Background
I am building a very social web-application in which there are several events that trigger social actions such as updating the user's Twitter status.
Currently, I use a library called "TweetMoaSharp" (.NET) to handle the Oauth workflows and events that trigger a status update or follow action work brilliantly as long as the user is briefly redirected to the Twitter authentication page.
To clarify, the user is not asked to re-authorize my app each time, but there is an unsightly flicker that lasts for 1-2 seconds while the user is directed to Twitter and then back to my app. This will annoy the end user as there are frequent Twitter interactions.
So--to relieve the situation, I use TweetMoaSharp to obtain an OAuth Access Token via the server and then store that token along with the user id returned from Twitter in my database. I then set a cookie on the client that contains the user's Twitter Id so that for future requests I can simply pass that ID to the server, grab the OAuth token form the database and do my business. No redirect required!
Problem Solved, Right?
Well, no. Stupidly, I overlooked the fact that this can cause a collision with multiple Twitter Accounts being used on the same page and ended up tweeting test-tweets to a second twitter account I own because I had changed Twitter sessions. This could happen to any user(s) who access multiple Twitter accounts from the same browser; a husband and wife for example.
Back to the Drawing Board
I thought to myself, "The Facebook JavaScript API" makes it super easy to get the id of the currently logged in user without going through a bunch of server-side token steps so I am sure Twitter offers the same approach." Ha! I haven't found one yet.
Bottom Line / Question
How do I get the ID of the currently authenticated Twitter user without redirecting them to Twitter (even for just a second)? If I can do this, then I can compare the returned ID to the one in my cookie and know if it is valid for my application's current session or if I need to have that (new) user authenticate as well so that I avoid "Tweeting" under the wrong account.
Thanks in advance.
Use your app tokens to do a verify credentials call
https://api.twitter.com/1.1/account/verify_credentials.json
The returned info is the logged in user.
Unfortunately limited to 15 calls per 15 minute window!
I have a Google Apps Marketplace (v2) app I am working on setting up Oauth2 for.
I've got everything working, but for some reason when I do a redirect to the authentication page, after, after you select which Google account to use (if like you're me and are testing, you have to pick one of several Google accounts you're currently signed into), I get sent to another page which seems utterly pointless:
This is bizarre and annoying, because I am logging in as the domain administrator!
Does anyone know a way to skip this screen, or what I might be doing to be cursed with this terrible user experience?
I just confirmed that having access_type=offline will always display this page, even with approval_prompt=auto. You will always get back a refresh token as well.
The only way to hide it is to remove access_type=offline on future login requests (ask only on signup).
I believe this shows up only if app requests refresh token for offline access. Also this should only appear first time you access the app after installation.
In order to skip this you need to update app to not request refresh tokens.
This is probably a repeat. However, the other answers haven't helped me out. So, here goes.
I'm working on an application and we with need to add 'users' to it. We'll be giving the option for people to sign in with Facebook, Twitter and LinkedIn. I've worked with these APIs before, however never combined them globally.
How can I maintain and manage these users that will use different services to log in. I'm confused as to how they would be stored in a database, would I need to have a different table for each different social service or is there a way to implement a table that will house all users in one place.
From what I understand, you're asking how to manage, store, verify users that will be logging in your application through different social services.
This is how we've implemented it through the various projects we've worked with. From the list of services you've provided we've worked only with twitter and facebook, so I can only speak about that.
Setup:
We have a web service that our iOS app communicates with such as when the iOS app needs to make a request call for user login the server would take the user details trying to login and gives back a response where the app would then do whats necessary.
We have a database stored on the server with a users table which is used to verify a user.
That being said, you need to understand whats common between most social services, or to at least know what the property is that is used by these social services to uniquely identify its users. In this case they all use email to identify users.
You'll find that when interfacing your app with these different APIs, they like to use a login session key used for unique logged in sessions.
So on your database you would store whatever details you want to save of the user, but know that you need to store atleast the username, password (encrypted), email (for identification, unique column), and login_session_key.
Just double check that linkedIn does have something like a session key that it creates when a user logs in with that method. Facebook and twitter do. Send at least the 4 main data properties needed (username, password, email, session) to the server You then follow this sort of approach:
New user
If the user that is new tries to login, the server first checks the email provided even exists in the database, if it does not then you sent a response back alerting the user that the user does not exist; your app would then take them to the register screen for example.
If the user is in the registry page, save all the details you want to store of theirs including username, password and email.
Members
If the user logs in the email will exist on the server side, its an existing user so just update the session key that was sent from the app on log in if the password matches, (in some apps these session keys are used through the life cycle of the application being used, with each request sending the same session key and if at any point the session key does not match during app interaction, it can be concluded that the user has logged elsewhere on another device perhaps.
if the password does not matches return the appropriate message.
That's about it really. We're able to store all facebook and twitter users in one table.
I'm working on a cloud-storage API, authorized via OAuth. Users of third-party applications can permit said application to access their files/data via our RESTful API.
Currently, we are limiting a third-party app access to a users account once. E.g., the Access Token table has a UNIQUE on the consumer column and the user column. This makes sense at first glance, as the user should never be sent to our service to authorize a third-party application twice, since the third-party would already know their user is already tied to our service and wouldn't need to be re-authorized.
However, what if this user has two accounts on the third-party app, and they want said app to connect to their single account on our service twice? This seems likely, given the prevalence of multiple accounts on services such as Reddit.
Here are the possible solutions I've come up with so far, none of them being perfect:
Display an error during the second auth request: This seems like a frustrating experience for the user, a "cop out" of sorts.
Delete the previous token: This would likely annoy the user, as their previous accounts stop working. Even if we display a warning, it would likely be hard to explain what exactly is happening.
Return the same access token as the first request: Each time the access is requested, a set of permissions are also passed along. The permissions for the second request could be different than the permissions for the first request. Also, not sure if this will violate the OAuth spec, as the secondly generated Request Token isn't tied to the Access Token properly.
Allow two to be generated: This would be confusing, as when the user visits their screen full of authorized applications to revoke one, they don't know which authorization is tied to which third-party account. We could ask for an optional third-party username parameter when the Request Token is generated to identify the different auth's (we currently ask for a non-OAuth-standard permission parameter already). But, this seems like it wouldn't be used by 99% of developers and could make application development more confusing.
What is the best way to handle this situation? Is there a standardized practice for handling this use-case?
I think your last case is the right way to go - Allow two to be generated
When the user visits his screen full of authorized application, it's not necessary to show him one and the same Application twice - you just have to delete the tokens associated with the app if the user revokes application access. That is, all his authorizations to the app with all tokens will go away with the revoke, which is fine.