Parse & Swift - Preventing simultaneous logins - Parse Installation Object when user uninstalls app from phone - swift

In order to solve a lot of problems I was having, I decided to prevent simultaneous logins by a single user. When a User signs into Parse, I check to see if there is an existing Installation with a Bool (isUserLoggedIn) set to true. If there is, the user is given a prompt to please logout of my app on all other devices before continuing. Once they do, they will be able to login.
This all working correctly.
However, I realized a potential issue. If the user logs into my app, and then deletes my app from their phone (before they logout), I never have the chance to set the Bool value in the Installation object to false. So, the user deletes the app, the Installation object (which contains their user objectId as well) still has the isUserLoggedIn Bool set to true.
When the user re-installs my app on their phone, and goes to login with their previously created account, my app won't let them login, because the prompt thinks that previous Installation is still logged in.
So, any ideas on how to solve this? I could solve it if I could get a persistent device ID, but apparently you can't do that anymore with iOS devices. Once my app is uninstalled, the device ID will change with the re-installation of my app.
I could also solve it, if Parse could delete the Installation object when the user uninstalls the app from their phone, but that doesn't seem possible either.
The last thing I thought of, was if there is a way to query installation objects with the users objectID, and for all of those returned, query the deviceToken for each device. Any deviceToken that is no longer valid, that must be the Installation object from the previous app installation, which I could then delete from Parse, solving my problem.
I'd really like to hear your ideas.
Thank you.

I ended up using Wain's suggestion from this question:
Handling Login on Multiple Devices using Parse iOS
I changed how I was tracking multiple installs (using the User class instead of the Installation class)

Related

With Visual Studio App Center (Hockeyapp?) can I have a user email me their crash log or identify themselves so I can find their specific crash?

Say a user is getting a really annoying crash and with their permission I want to help them and fix it. But also say I have a ton of other users also experiencing crashes so their specific crash is hard to identify.
https://learn.microsoft.com/en-us/appcenter/sdk/other-apis/ios#identify-installations
How can I (with their permission) pull their crash log out? I know each install has an anonymous Installation ID or whatever, if I make theirs visible in the app, is there a way to have them email that to me so I can search crash reports based on that? Or is there a way to just straight up have them email me their crash report?
You can do this by attaching a user's ID to the crash reports in App Center: https://learn.microsoft.com/en-us/appcenter/sdk/other-apis/ios#identify-users
This can either be the ID from your own account system or you can for example just re-use the anonymous Installation ID generated by the App Center SDK for this. Then, you would also need a way for the user to tell you their ID, either by surfacing it in the UI, by automatically attaching it to a support request, or similar.
Afterwards, you can use App Center's search functionality to search for crashes by that ID: https://learn.microsoft.com/en-us/appcenter/diagnostics/search

Facebook app_scoped_user_id duplicate

Alright, strange problem that I'm encountering:
Our website uses Facebook to log in. Currently I'm using HybridAuth to get the user's information - I'm storing the identifier ('app_scoped_user_id' as I've now learned), and using it to check when people try to sign up or login through Facebook.
A few weeks ago, we went through a total rebranding of the site, separate domain entirely. I ended up creating a second Facebook app through their developer console for the new domain, because it wouldn't let me add that domain in the settings of the original one. I wasn't aware that the identifier coming back was within scope of that particular app - hoping that this won't be a major hurdle to fix.
So a problem occurred where a user went to sign up with Facebook, and was logged in as an existing user who had signed up under the old domain - so the app_scoped_user_id for this new user matched the app_scoped_user_id for the old user and signed them in. Clearly an issue.
Now the weird part is that for old users who had signed in through the original app are signing in fine through the new app - definitely sending through the new keys, connecting to the new app, but apparently the app_scoped_user_id being returned is identical between the two apps.
SO... am I not understanding things properly? If the app_scoped_user_id is different between two Facebook apps, is it possible to bring over the used ids from one app to the other?
EDIT******
Problem solved... if anyone else ends up making the same silly mistake I made, this is how I solved it:
Since the info coming back from Facebook includes their e-mail... just checking their e-mail field to see if they already exist, and assigning the new token to that entry. Obviously there could be a few cases where either the user changed their email on Facebook, or changed their email within our app, but our user base isn't too large yet, so glad to set this right now.

Can't see Facebook app after adding myself as test user

I'm an admin for my Facebook and tried to add myself as a test user as well. After confirming and inputting my password and completely shut me out of my app and I can't get back in. Neither can he other admins.
How can we restore our app, it doesn't appear anything broke and the app still exists. Just no one can get into it.

Facebook App Permission Getting Toggled Somehow

I have Facebook's SSO working properly in my iPhone app and most of my users have not been experiencing any issues. However, a small number of them have been reporting errors with Facebook Connect and not being able to create an account. After an email exchange with one, we determined that the app permission toggle under Settings->Facebook was somehow set to disallow my app from using Facebook.
I have since added an error message telling the user this might be the case but my question is how did this switch get toggled in the first place? It would seem that a user would have to manually toggle this switch, right? I also looked for an API method that might do this e.g. rejecting Facebook SSO the first time a user saw the dialog asking for permission; I could not find any such code.
Any ideas? I'm hoping this problem will solve itself with the error dialog I've put in but if possible, I'd like to remove this issue altogether.
As far as I know, using the native dialog with iOS6 and rejecting the permissions request (the first one, at least, not sure about requests which are asking an existing user for more permissions) will toggle that switch
If you need to debug, try uninstalling the app from your facebook profile (a HTTP DELETE request to /<USER ID>/permissions will do this, or you can do it in the facebook app settings), remove the iOS app, then install it and try to connect for 'the first time' again

reauthenticate feature has changed its behavior?

In my application to be able to switch to another user, I use the "auth_type=reauthenticate" parameter for the "https://www.facebook.com/dialog/oauth" URL. This worked for a long time. I was able to log in using other FB user than last logged. (e.g. shared PC)
Today I found out that there is no longer possible to change the user. Only re-enter password. Moreover, there is no "Cancel" button (used "dispalay=popup").
I can't find something about it on developers.facebook.com
Is anybody know something about it? Is it temporary bug or anything else?
from :
https://developers.facebook.com/docs/facebook-login/reauthentication/
Note that apps should build their own mechanisms for allowing switching between different Facebook user accounts using log out functions and should not rely upon re-authentication for this.