Messenger bot: You cannot access the app till you log in to www.facebook.com and follow the instructions given. No instructions were given - facebook

My messenger bot that was running for two months but this night something changed and for unclear reasons, I can't POST back to Facebook which returns an error as a response.
From begging:
This is the communication scheme
# VS - alias for the Server running chatbot
# this is what should happen
1. User -> message -> FB # User sends a message via messenger
2. VS <- message <- FB # Facebook does its thing and send me REST API POST request
3. VS -> response -> FB # I send the response meant for the User
4. User <- response <- FB # Facebook forwards the response to User
# this is what is happening
1. User -> message -> FB # works
2. VS <- message <- FB # works
3. VS -> response -> FB # works
4. VS <- error <- FB # FB returns an 400 error and User gets no response
This is the error returned in the fourth step.
# The error response from step 4
'{"error":{
"message":"You cannot access the app till you log in to www.facebook.com and follow the
instructions given.", ### !! above !! ###
"type":"OAuthException",
"code":190,
"error_data": "{\"checkpoint_url\" : \"https:\\\/\\\/www.facebook.com\"}",
"error_subcode":459,
"fbtrace_id":"A9MjzGGqQfKY2vPsszXQemu"
}
}'
I did as said in the message field but there were no instructions on facebook.com nor the developers.facebook.com. I checked from the correct account.
I did change a thing in server code, but it was a simple bug fix that shouldn't have had an impact on communication with Facebook. Obviously, I have tested it and everything worked fine.
But overnight FB decided that everything was not fine and started returning errors to every response sent (response is the third step in the communication scheme).
Do you know what this error is about or maybe where can I find help because Facebook doesn't provide real support?

Quick fix:
Log in to every administrator account of the app and check notifications or
possible security issues. For me it was changing the password of an account
that I don't use daily.
Generate new Access Token in App Dashboard/Messenger/Settings and reconfigure
your server to use it.
Longer version
The app has two administrator accounts, one is my usual and the other one was created specifically for this project (what was unnecessary).
Looking from my main account, I couldn't find anything that would tell me what is wrong, when writing this question, just to be sure I checked the other one. FB prompted me to change my password for security reasons because someone tried to log in from the USA (but I haven't tried to log in to this account lately).
I changed the password and looked for notifications that would tell me what was wrong. Nothing. Error response didn't change either in logs.
Today with nothing better in mind I switched from: requests.post("https://graph.facebook.com/v2.6/me/messages")
to:
requests.post("https://graph.facebook.com/v6.0/me/messages")
and checked logs, where I found this response:
"error":{
"message":"Error validating access token: The session has been invalidated
because the user changed their password or Facebook has changed the
session for security reasons.",
"type":"OAuthException",
"code":190,
"error_subcode":460,
"fbtrace_id":"Ay7KPJ9_gtv5s3ebKjm5LG_"
}}'
Now I did exactly what it said and generated a new Access Token in
App Dashboard/Messenger/Setting and reconfigured my server. This was it.
Then from curiosity, I changed back the v6.0 to v2.6 and everything still worked fine.

Related

NetSuite SuiteTalk REST Web Services - Invalid Login Attempt - Sandbox Account ID vs. Account ID in URL [duplicate]

I am trying to use the NetSuite SuiteTalk REST Web Services to access NetSuite CRM data.
I have the access up and working in production. Able to retrieve record data and metadata.
I am now trying to set up access in the sandbox for more in-depth testing.
In the sandbox I have:
- Enabled rest web services
- Enabled token based authentication
- Given user concurrent web services permission
- Given user Log in using access tokens permission
- Created an integration
- Created an access token
All of these actions mirrored what was done in production.
When I attempt any kind of GET to the web service, I receive a 401 - Invalid login attempt.
When I check the Login Audit Trail, I don't see any record of the GET attempt, failed or otherwise.
Is there something of a systemic nature that I have to do additionally in the sandbox to enable rest web services? Above and beyond enabling it in SuiteCloud/SuiteTalk?
The fact that I see absolutely nothing in the audit trail makes me believe that something is still "turned off".
===> 4/4/2020 Update
ed14 and Nihkil,
Thank you for your responses, and sorry for the delay in responding back.
The hyphen to underscore in the realm did not help me unfortunately.
Let me recap recent attempts:
1) Started by verifying that REST API testing in production still works.
2) The sandbox was refreshed by a CRM admin. The application was still there, but my access token was not. I created a new one in the sandbox.
Is it possible to delete the application? I cannot see any way to do that.
3) Tested with existing Consumer Token and new Access Token. Got the same response as from my first post: "title": "Invalid login attempt, for more details see Login Audit Trail.",
4) Tested by slightly modifying the URL to make sure I was not going to a black hole somewhere. It gave me the expected error.
5) Tested by modifying the realm: Realm 9999999-sb4 to Realm 9999999_sb4 It gave me an error which leads me to believe that my original realm is correct: "title": "An unexpected error occurred. Error ID: k8hd8pqej3unxblmaoik",
Again, none of the tests show up in anywhere in the audit log as a failed attempt.
Not sure where to go from here? Delete the sandbox application (if possible) and start again? Or new application in sandbox?
Thanks for any and all help.
Bryan Hunt
I had the same issue using the sandbox. Apparently there is a mismatch between the account ID (used in realm authorization) and the account ID in the URL.
The account ID (realm): XXXXX_SB1
The account ID in the url: XXXXX-SB1
The SB should be in upper case.
This solved the problem for me.
As #ed14n and #nikhil-abraham said, changing - to _ in authorization realm and put the SB in UPPER CASE solve this problem here.
If you are using POSTMAN template provided from NetSuite, your envs should be like the image below.
In Postman in your request tab and then in the authorization tab in the advanced section there is a field called Realm. Put the account id in the realm field with underscores.

FIDO U2F Key: Sign authentication challenge in Chrome returns error code 4 (works in FF)

We are trying to add authentication via Yubico FIDO U2F Security Key to our admin website.
This works in FireFox with the U2F add-on installed but signing a challenge (using javascript) to log in keeps returning {errorCode: 4}.
Does anyone know why that might be happening or how I can debug what is going wrong?
Thanks in advance.
Details
Our website is made in Java with the ZK Framework. On server side we use the java-u2flib-server library. We sign the requests on client side using javascript in the zul files using the high level api functions u2f.register and u2f.sign.
Registration
To register a key the user first enters name and password and submits. The server creates the RegistrationData and goes to a second page. There, we use javascript function u2f.register. In the callback we send the response with the DeviceRegistration to the server.
This works both in FireFox and Chrome.
Authentication/login
The login is done similarly. When submitting the first page the server gives the DeviceRegistration json and a challenge to a second page. The page uses u2f.sign and sends the DeviceResponse to the server in the callback.
This works in Firefox but in Chrome, u2f.sign keeps returning {errorCode: 4}.
According to the documentation this means the device does not know the received DeviceRegistration but that seems unlikely since the same code works in firefox and I checked that they receive the same json from the server.
Error code 4 - DEVICE_INELIGIBLE -
The presented device is not eligible for this request. For a registration request this may mean that the token is already registered, and for a sign request it may mean that the token does not know the presented key handle.

Facebook Oauth Servicestack not working

We have been using servicestack as framework for web services, we also uses its SSO with FB, LinkedIn, GooglePlus features.
We enable them like this
Plugins.Add(new AuthFeature(() => new AuthUserSession(),
new IAuthProvider[] {
new FacebookAuthProvider(appSettings),
new GoogleOAuth2Provider(appSettings),
new TwitterAuthProvider(appSettings),
new LinkedInOAuth2Provider(appSettings)}
From 3/27 the FB SSO stops working on our site but the other SSO's like LinkedIn works fine. When I debug for facebook SSO, we are getting the Auth_Code from the FB back to our services, but I am assuming the server to server communication is failing while passing(code, secret). It is just an assumption made as the Auth_token is not set in session. If you came to know that FB updates something in OAuth process that ServiceStack not follows or anything like that, please provide me that info links.
I am wrong in my assumption "we are getting the Auth_Code from the FB back to our services, but I am assuming the server to server communication is failing while passing(code, secret). It is just an assumption made as the Auth_token is not set in session." Using the fiddler I am able to see the server-to-server communication for exchanging Auth_Code, Client_Secret with Access_Token. I see the Token response. After that I was taken back to my ReferralURL. In my Referral end point I am getting the Usersession.ProviderOAuthAccess, It has the Facebook provider but I don't see any Token information in it. This is really an interesting chase. Please help me with any other ideas to test.
I found added info: After getting the Access_Token froom FB, the immediate call is https://avatars.io/facebook/?size=medium initiated by service-stack.
https://github.com/ServiceStack/ServiceStack/blob/v4.0.50/src/ServiceStack/Auth/FacebookAuthProvider.cs
At line 73 of FacebookAuthProvider.cs it calls OnAuthenticated function whoch calls OnAuthenticated function at line 171
https://github.com/ServiceStack/ServiceStack/blob/v4.0.50/src/ServiceStack/Auth/CredentialsAuthProvider.cs
which calls the function SafeAddMetadata at line 177 of the file
https://github.com/ServiceStack/ServiceStack/blob/v4.0.50/src/ServiceStack/Auth/AuthMetadataProvider.cs
Finally triggers this:
"http://avatars.io/facebook/{0}?size=medium".Fmt(tokens.UserName));
Which seems that the tokens.username is empty from my network flow. This issue is beyond my thinking. It used to work, just stopped suddenly not sure what happened, we even don't even upgrade servicestack or servicestack.OAuth packages.

LinkedIn Share feature

Post LinkedIn changes (around May 2015) have disabled our use of the share feature, via API call using the URL http://api.linkedin.com/v1/people/~/shares?format=json. We are now receiving a "403 authorization failed".
Steps taken to rehabilitate our share function:
Confirmed that ClientId & Client Secret keys are still the same as being used in our app
The Default Application Permissions have been confirmed, w_share is selected...which used to be rw_share (no longer available). Other selections made are r_basicprofile, r_emailaddress, & rw_company_admin...which are seemingly not related.
Authorized Redirect URLs are still applied for the domain we are using our application under.
Content type has been set to "application/xml", as suggested by other postings.
We have tried for months...hoping that any post changes to LinkedIn would have resolved our problem, yet nothing we have researched has helped. We figure that this might be a glitch from the permission modification update done by LinkedIn...since our code has never change, yet has worked for 2+ years prior to the May 2015 changes.
We would appreciate any insight as to what is going on here....as we are continuing to have this problem.
I found the problem, it was because the security of Linkedin changed. We had to had to alter the statement:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Ssl3;
to this:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls;
If you are relying on the "default application permissions", you may also want to double check that your OAuth code is not still requesting the old (no longer available) member permissions (e.g. rw_nus) via the ?scope= URL parameter, which will trump the "default application permissions" settings you've defined in your LinkedIn app's config.
Otherwise, the w_share permission should still be providing you the ability to post a share to LinkedIn.

Error code 100 (Can only call this method on valid test users for your app)

getting the error {"error":{"message":"(#100) Can only call this method on valid test users for your app","type":"OAuthException"}} whenever trying to write to any facebook end point. Reading (GET) works fine, writing (POST) fails. Does anybody know how to resolve this?
I have also opened a ticket on FB dev site:
http://developers.facebook.com/bugs/184198634991192?browse=search_4e93328871c8a3231774584
The problem does not occur is I would shoot the POST request from my browser as if I am the user.
The problem does occurs only when sending from our servers on behalf of the user from one of our dev machines which have other subdomain names instead of www (such as dev1.blablabla.com & dev2.blablabla.com, while the app is registered to www.blablabla.com).
So the question is, does facebook attempt to do a reverse DNS lookup on all write requests to verify the source?
I believe your requirement is to get the user details of the owner of Facebook access token (normally the currently logged in user)
For that you have to issue a GET request and not a POST request.
The reason why it works when fired from the browser is that when you submit a query through the address bar it is send as a GET request, and when sent from your server it is send as POST and fails producing the error message mentioned in your post.
Facebook doesn't do a reverse DNS lookup on your write request and not need to configure anything in your server related to it.
Hope the answer is clear enough for you.