We Keep Coding

Facebook app review for API permissions still rejected

Our web application aims to allow our users to share photos with comments directly from our platform.
Since May 10, I have made several permission requests from Facebook for the following permissions:
pages_manages_posts
pages_show_list
instagram_content_publish
pages_reads_engagement
ads_management
instagram_basic
https://drive.google.com/file/d/1fv83sv8Z7EVmTEuNrIaVCpcYnHKY5H4A/view?usp=sharing
As and when requests some pass others not. In addition, our web application has not undergone any change since the first request, since everything has been working on our side from the beginning. And yet some permission seems to be released randomly as the different requests.
We only have the "instagram content publish" permission left, however as it always resulted in a refusal, we changed our Facebook developer account. Indeed, our new developer Facebook account has a company verification and we thought it would have more weight then.
However, on the first request on this other account, all permissions were denied, while there was only one left on the other application. And again, nothing had been touched on our web application.
We don't know what to do anymore because we can't get in touch with anyone.
Has anyone encountered the same problem? How to get in touch with an engineer / developer at Facebook?

Google Oauth - Where to sign in users, backend/frontend

What is the difference between using Google OAuth and signing in users at the frontend of the application, and signing in users at the backend side of the application?
Example: Signing in users and getting the ID and a auth object in React or letting Node/Express handle everything, the prosess, redirecting and store it in a database.
Is there any advantages for one or the other methods, which are most common and are there any "rules"?

What is the difference between using Google OAuth and signing in users
at the frontend of the application, and signing in users at the
backend side of the application?
So to clarify to everyone reading this, signing in users at the backend side of the application is another way of saying OAuth for servers and signing in users at the frontend of the application is OAuth for JavaScript browser applications such as React.
Signing in users via OAuth for servers and browsers results in a 'token' that a server/browser can use to make requests on behalf of the user. We are asking the user to provide us access to their information via an outside service provider such as an email address, identification of some sort and it will be inside that token as well as some possible permissions that allow us to take actions on behalf of that user.
Is there any advantages for one or the other methods, which are most
common and are there any "rules"?
Server-side OAuth is usually used when we have an app that needs to access user data when they are not logged in. So if you are attempting to build an application that needs to access the users email every ten minutes and possibly delete emails on the users' behalf, you would want to be able to access their email account every 10 minutes regardless of whether they are logged into our application. So for this use case we want to make use of Oauth for server.
Otherwise, if we are not trying to do anything on behalf of the user except sign them into our app, then we can just go with OAuth for browser.

Those two things are very different. Without knowing the specifics of what you're trying to accomplish, you should know as a general rule that front-end-only authentication and authorization leaves you extremely vulnerable.
If someone knows JavaScript well, or is using editing plugins, or any of a million different things, they can bypass much front-end authorization. Or they could just watch to see what calls your app makes to the back end, then simulate those calls from something like Postman, bypassing your web front end entirely.
If you're not securing your backend, you're not secure. Typically systems do both.

It is just a different ways of registering users to our website.
Signing in users at the frontend using OAuth can be very handy as it enables our users to not go through our boring forms in our website. Using OAuth is just one click away from registering users in our website. Beneficial to both the clients and developer.We are provided with the general information about clients by the provider(google,facebook) just clicking on one button.
Signing in users at the backend side is the traditional way of registering our clients. Here we force our client to fill the forms in our website(which may be painfull if it is a long form) and all the filled data is stored in our database.
So they are both different ways to register clients to our websites. Both are used very often. It depends on usecase and needs. Oauth can be used if you want to attract more clients by registering them just by one click.

Grant Access to a Shared Mailbox From an Application

Within Office 365 its apparently not possible to assign a security group to a shared mailbox. This means that all users need to manually be added to the shared mailbox, which is a pain.
However, Microsoft Graph appears to offer a way to subscribe to changes to a given group. As a result my thought was to build a simple azure function application that receives a web-hook from Microsoft Graph when someone is added / deleted from a specific group, and promptly adds / removes the user from the list of shared mailboxes.
The problem I'm having is that Microsoft Graph does not appear to have an API call for granting a user access to a shared mailbox; and I haven't been able to find another Microsoft API that will allow it.
The only way I've discovered that can even do this programmaticly is with PowerShell, which requires that I create a user to authenticate rather than granting application access. PowerShell also only has experimental support for Azure Functions right now, and I'm not even sure if Azure Functions supports Exchange Online PowerShell calls or how to install it if needed.
Does anyone know a way to do this with REST calls or JavaScript specifically, or better yet to do it with Microsoft Flow without writing code?
If I don't get any answers on the preferred method soon, I will except a solution on how to do this with an Azure Function or Microsoft Flow and PowerShell.

Instead of an Azure function, you could use Azure automation to create an Azure Runbook that will execute your PowerShell code.
The Runbooks allows you to import modules giving you all the functionality you need to do the Exchange Online PowerShell. It also allows you to store credentials of an Account with the correct level of permissions. (While testing you can use an Exchange Service admin account or a Global admin).
So you could create an Azure AD user, use Exchange RBAC rights to scope it down to only have permissions to what it needs to do for security reasons, then store the creds of that user in the Runbooks credential functionality.
The Runbook can then be executed from a webhook.
A small note, you cannot add a security group, but you can add a mail enabled security group and give it rights. The group can be hidden from the global address list in Exchange and just use some bogus mail address on the .onmicrosoft.com domain of the tenant.
Only thing to note, this method of using groups for permissions does give the user the correct access rights, but, the mailbox will not automatically be added to Outlook.
The reason for this is that Exchange adds an Automapping flag to the object you give access rights on the mailbox. But setting this flag on a group does not recurse and also add the flags on users, so users would need to manually go into Outlook and tell it to open the mailbox.
How to manually test in Office 365
Confirmed to work 03/12/2018
Adding a new mail enabled security group in Office 365.
Creating a new shared mailbox in Office 365.
Adding a user to the mail enabled security group.
Open the OWA logged in with the user you added to the mail enabled security group
Select "Open another Mailbox" and selected my shared mailbox.
This is the easiest way to test if the permissions have carried over. But do mind that in Outlook for desktop, the user manually will need to add the mailbox in the settings page, since the auotmapping flag does not carry over.
Also take note of Exchange Online replication time. At its worst it may take up to 30 minutes for everything to propagate properly, but it usually works within 5 minutes.

Office365 IMAP Access: User is Authenticated but not Connected

I'm building my own IMAP client using node-imap, and I'm testing it against accounts on office365.
Since it's under development, I tend to hammer on the IMAP server more that I would in production, but not necessarily what I would consider to be too much.
Occasionally, I start getting the IMAP response "BAD User is authenticated but not connected". This comes after the first command after a successful login.
This is not related to password changes as other similar articles indicate, as my passwords are not changing during this time.
When this happens, the account seems to get locked up for a period of time. I seem to be able to jiggle it free by disabling then re-enabling IMAP on the account via the office365 admin panel.
So it looks like there's a circuit breaker of some sort in the IMAP interface on office365. Microsoft documents a limit of 20 concurrent sessions. In my case I am only opening one session at a time, but I am then closing it and re-opening it again soon after (debugging), so if I am running afoul of a limitation, it's not documented anywhere i have read.
Microsoft support has been helpful but unable to help me root cause this.
In order to take this app to production, I need to know what causes this to happen.
Has anyone else had a similar experience with office365?

You may want to take a look at the Outlook REST APIs rather than IMAP. The REST APIs are the recommended development API for Office 365 and are much better suited for app development with features like webhook based notifications, and are constantly evolving with the new features and functionality in the service. They also don't have the session oriented nature that IMAP has that results in the kinds of problems you are hitting.
There is a NodeJS quickstart guide to O365 here: https://dev.outlook.com/RestGettingStarted/Tutorial/node

you need to perform 2 operations on exchange online using powershell
You need to create the service principal
New-ServicePrincipal -AppId {clientid} -ServiceId {enterprise application objectid} -Organization {tenantid}
you need to grant your service principal access to the mailbox,
If the principal does not have the access, you get "user not connected"
Add-MailboxPermission -Identity {email} -User -ServiceId {enterprise application objectid} -AccessRights FullAccess
See "Register service principals in Exchange" at
https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth

If you have already verified that your password is correct (by logging into your mailbox from the web) then the issue might be Exchange server keeping a list of all your active login sessions.
Try signing out from all other locations by clicking "sign out everywhere" on the account security page https://mysignins.microsoft.com/security-info and then retry signing in again.

Office365 will accept connections and successfully authenticate even when the user doesn't have permissions to access the server by IMAP, and this is the exact error it gives in that situation.
To resolve it, go into the Office365 panel, open the user, and ensure that the IMAP permission is checked.

How to detect joined date via Facebook, Google OAuth

My website allow users to signup by their Google or Facebook account. But some users use clone account to signup for spamming, so I want to detect and allow only Facebook or Google account which was created at least 1 year ago to signup.
I know that Facebook and Google API do not allow to see that information, do you have any opinions about this, please help me.
Thank you vẻry much.

I have few thoughts over this. In my view I do not think that information can be available via API. Both Facebook and Google have strong layer of security with some abstractions in terms of data they shared about a perticular entity. IMHO (in my humble opinion), it appears too much internal to me regardless of the fact that you have fair enough information being shared by their rich set of API.
Here is an overview of what Facebook has mentioned regarding permissions:
When a person logs into your app via Facebook Login you can access a
subset of that person's data stored on Facebook. Permissions are how
you ask someone if you can access that data. A person's privacy
settings combined with what you ask for will determine what you can
access.
However you can check what permission you have been grant access to in your app by Facebook.
For Google API, i did not see/find such information. Check obtaining user profile section.
So is there anything we do to check spammers?
Well, not in kind of way we anticipated, but one thing that could be helpful is the email verification. Most of the spam users do not like to provide valid/verified email addresses while sign up.
Calling the Facebook Graph API like https://graph.facebook.com/version/me/?access_token=token&fields=verified (where verified can be true or false). I saw some users report that it brings in whether the account has been verified, not the email.
In Google API, we can get the profile by calling the people.getOpenIdConnect endpoint. This method has email_verified property which returns true only if the email address is valid.
These may or may not be helpful but something is better than nothing until some better option get available in future versions of API.
Conclusion
Besides it is certainly not in scope of a developer using the API to control fake/spam users from signing up on either of these social networking giants. I believe that apart from checking the authentication, it is not easy to detect/filter out the such users out of million users even at their end.