I am currently trying to find which id the logged in user has, but the documentation does not show any clue whatsoever indicating how this can be achieved.
I need to know the logged in user id to tell whether or not the user is working on a case so he can start/stop accordingly.
Since the API only returns the ids of the users currently working on each case, there is no other way for me to show the user if he is working on that case without knowing his id.
I was expecting this id to be provided after successful login, but it is not and I cannot find a way to discover the id.
Is there even such a way? If there is then how can I get it through the API?
So I finally found a way to discover the logged in user ID, the command is viewPerson without passing a user id:
Takes only ixPerson OR sEmail. If no parameters are supplied, the user currently logged in is returned.
http://help.manuscript.com/the-fogbugz-api/users#View_a_User_cmdviewPerson
As to why this eluded me was due to the wrong description of the command return, which states the following:
The case number of the edited case.
Now I am able to cross-check the id with any case I need to find out whether or not the logged in user is working on a certain case.
Related
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.
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)
Context
I am using Parse.com as my backend for a mobile app. I use Facebook login only for now.
Assuming the user has logged in with Facebook and now has an account created on Parse already.
Question
Every time the user opens the app, should I do a check if his account is still valid by using PFUser.currentUser().become()? Or should I use the cached PFUser.currentUser()?
I have found out that if I delete the user account in the Parse backend, if I don't do a become(), the PFUser.currentUser() is still valid, even if the account does not exist anymore.
What is the best practice?
It's generally better to add a column to the user such as 'disabled', and when the app starts you can refresh the user, check that flag and display a message to the user and logout. That, from a user point of view, is similar to using become (at least as long as you check and notify the user).
So, you should do something if you're going to be removing or disabling users in the background. The main question is wether you fully delete the account or just delete the contents but leave the (empty) user in the system as a record.
In this excellent post / answer: Anonymously Log In to an App with iCloud Apple ID there is discussion about how to retrieve an app-specific ID for a user (fetchUserRecordIDWithCompletionHandler: method on CKContainer).
Further, there is discussion about how to request additional details from the user (fetchRecordWithID:completionHandler:).
My question (I don't have a Apple Developer account) is: what do these two steps look like (if applicable) to the end-user? Specifically,
Does the initial request for the simple RecordID require user permission?
If so, what does the the prompt look like?
What does the second request (to get email address or name data, for example) look like?
Screenshots or examples of apps currently using this framework are greatly appreciated.
The call to fetchRecordWithID: doesn't actually prompt the user. The record fetched will be empty, but you can store any values you'd like on it.
If you make the current user discoverable in your container then:
Anyone with this user record ID can look up the first and last name of the user
Anyone can find this user's record if they search for one of the email addresses associated with the account
Becoming discoverable exposes information about the user to other users of that container, so CloudKit will prompt the user with an alert to make sure they want to become discoverable.
You can request discoverability permissions by calling -[CKContainer requestApplicationPermission:CKApplicationPermissionUserDiscoverability...]
I'm using forms authentication to log users onto my website.
But what happens if someone is trying to login with the same details from different machines at the same time? Is there a way to check this?
Ideally, I'd like to display a message to the second attempt saying that that user account is already logged in..
Thanks
Hold that information server-side (the list of users that are already logged in). Then, on each login, check if not already in that list.
When ever a login happens save the values of Username and Password in Sessions and after that for every login check with the already logged in values in the sessions, if matches display a message and dont allow to login.