Help - JFBConnect > UserMap.> FB App Athorized

Users can deauthorize the app from Facebook at any time. When that happens, Facebook calls the deauthorize callback set up in the application. JFBConnect then sets that flag to 0 on the usermap. In order to authenticate on the site again with Facebook credentials. the user will need to connect again to the Facebook profile with the Joomla user.

If they're not getting the prompt again to accept the app when using the Login with Facebook button again, it's safe to delete the usermap as long as
1) you have the "Automatically Link Users by Email" setting enabled in JFBConnect > Configuration and the FB account email matches the Joomla account email (or else a new account will be created
or
2) the user is logged in and SCLogin has the "Show Connect Account Button(s)" settings enabled. They can then map the logged into Joomla user to the FB account.

-Melissa

Looking at the code, yes I believe there's just a flag set on the user and it's not removing the user map row. I can't figure out what we're actually doing with that authorized information that's useful. I'll have to check with Alex since he wrote that logic.

I mapped a test user to my localhost page and deleted the authorization on the user's FB settings. I attempted to delete the usermap row and try to re-map the user again but was getting "Login Error. There is an error in logging you into this application. Please try again later." I'll have to investigate this further.

-Melissa

We're still investigating the cause of an error after de-authorizing an app, but I wanted to respond to your other 2 questions.

2) When a user de-authorizes, we use the following code to set the updated_at date to the current UTC time. Looking at the user component, I see how we can format it to the current timezone of the server to display that better. I've added an item to our todo list.

3) While it may sound simple and obvious, unfortunately, most social networks do not allow you to get the user's profile URL. There's a lot of reasons for this, but one is because admins started spying on their users (similar to what you're saying with 'check users when needed'). Facebook disabled this ability to get profile URLs back in 2018. Others never had the ability. There probably are some networks that we could fetch the URL from, but it's very inconsistent, so we don't do it.

This is Facebook's announcement post of the change:
developers.facebook.com/blog/post/2018/0...anges-address-abuse/

Disabling the ability to resolve the app-scoped user ID (ASID) returned by Facebook Login to a Facebook profile page, even for logged-in users.

Prior to this, we did link the profile icon in the user map to the user's profile...

I hope that helps with some background.

Thanks,
Alex

We're still investigating the cause of an error after de-authorizing an app, but I wanted to respond to your other 2 questions.

There are two different ways that I found to deauthorize the user. In a Facebook profile > Settings > Security & Login > go to the App that was authorized and either A. click "View and Edit" and remove from there or B. just hit the remove button. I just tested again and I did not receive the Please try again error as before, so maybe that was just an api fluke.

* If the mapped user is not logged into your Joomla site, they will be prompted to accept the app again when they click the login with FB button on the next login.
* If they're logged into the Joomla site already, they will not be prompted to accept until the next FB login. The "Connect" button in SCLogin will not be displayed if the deauthorizeUser callback is performed.

After talking with Alex, it seems as we're just turning the Authorize bit to 0 in the usermap area, but not doing anything with it except display it in the backend. We do not delete the mapping to the FB user, because the user can choose to log in and accept the app again and we don't mess around when mapping the "new" connection and accidentally creating a new Joomla user depending on the website's JFBConnect configuration setting.

Hope this clarifies things for the authorize user.
 

It's not a bad idea and likely pretty straightforward to implement. Sending an email is not difficult. However, when we implemented the deauthorize callback functionality, we assumed other social networks would have similar notification functionality at some point... that never happened.

Can you let us know what you'd do when you received such a notification? I'm mainly asking because we haven't had many users discuss this functionality. It's helpful for us to know why the email is useful for us to implement it. If it's just 'to know' that someone deauthorized without much to do in response, then I'm not sure if it's something we'd add. If there's a really good use case, we'd like to know that as well if there's something we could implement for a better experience.

Thanks,
Alex