FacebookOAuthException: Error validating access token on WP7 using Facebook C# SDK - windows-phone-7

I have a strange problem with the Facebook C# SDK on Windows Phone 7. I am using the SDK to post pictures to users' walls. For the first authentication and the first few posts, it works great. After a while (I have a feeling the magic cutoff is 24hrs) I start to get an error on every post:
FacebookOAuthException was unhandled
(OAuthException) Error validating access token.
This happens after my line of code that does the actual post has run...
m_facebook.PostAsync(#"/photos", parameters, PostComplete);
... but before my PostComplete callback function is called. No code of mine is running when the exception happens. My Application_UnhandledException is not called - I get the error in a dialog in the middle of the screen in VS, and it says that no source code is available.
If this exception means I need to show the login screen again, that's fine - right now I'm both not sure what it means and not sure how to trap the bugger. Any help appreciated.
Chris

What publishing permissions do you use?
By default, access tokens expire after a short time period to ensure applications only make requests on behalf of the user when the are actively using the application.
For getting a long-lived access token, you need to ask for the offline_access permission.

Related

Custom google home action should always reconnect to get it working

i have a custom google home action implemented as described in the documentation (Oauth2 setup, sync, execute, etc... setup) and all works as expected on my Google home app and my google home physical devices.
Now, every now and then i need to reconnect the app in the Google Home App because it seems the app cannot reach my devices after some time. I checked my Oauth server if the refresh tokens are working ok and they do. Also my access token expires after 20 minutes and me reconnecting to the app should be done after some hours so the refreshing works in my opinion.
Now, are there any restrictions in using the TEST of the google home action?
The case i wrote is specific for personal use (intergration with personal server and domotica system) so i am actually not planning on releasing it, I just want to use it for myself. Is this allowed? Can i just leave my action in 'test' forever for such purposes?
EDIT: 18/05/2022: custom actions still working flawlessly after 6 months in test :-)
EDIT: 02/02/2023: custom actions still working flawlessly in test :-)
Additional question:
If i have to submit the app for release, i cannot meet the expectation in implementing state report as i have no control over the usage of buttons pressed at my home domotica. Is State Reporting also accepted when i report the state of my devices over time (let's say, every hour?)
tnx
EDIT:
So it seems there is something wrong with my refreshing of the tokens but i don't know what. When i try through postman, all works as expected, in stackdriver logs i see this :
jsonPayload: {
#type: "type.googleapis.com/google.identity.accountlinking.type.AccountLinkingError"
errorReason: "Failed to get response from 3P. 3P returned malformed response like invalid response code or un-inflatble body."
request: {
body: "grant_type=refresh_token&refresh_token=REDACTED_VALUE&client_id=qbusauth&client_secret=REDACTED_VALUE"
method: "POST"
uri: "https://******.azurewebsites.net/token"
}
sessionId: -1039956344
step: "REFRESH_ACCESS_TOKEN"
If you don't plan to submit your Action for release, you'll just need to occasionally re-enable device testing through the console.
To minimize the number of query intents to your fulfillment, you should implement Report State and proactively send device states to update HomeGraph. You would have to implement this if you decide to release your Action.

How to handle sign out/in with Apollo client websocket and keep a working subscription?

I have a sample React/Apollo application on codesandbox that tries to handle sign out / sign in actions with a subscription (to a sample Hasura GraphQL server with JWT auth enabled). The workflow is illustrated in below screenshots (To reproduce, check logs and click sign out button; refresh preview if required).
I tried to handle it by resetting the websocket connection each time it should either clear the subscription (sign out) or retry (sign in) (wsLink.subscriptionClient.close(false, false)). But the errorLink (Apollo middleware) is not called any more after signing out, so I don't know how to catch it cleanly to trigger a sign in / re-subscription. However, the component keeps receiving errors. The error is somewhere but the error link is not aware of that.
If the error can be caught by the error link, I can plug all the logic I want to reauthenticate and I'm happy.
There are actually 2 questions here:
How can I ensure the error link continues to catch the errors after a sign out (here: websocket reset)?
What's the best way to handle sign out/in with Apollo websocket, if not this approach? (Ideally, I would like to remain on the same SPA page, interrupt the subscription, clear local data, show a sign in dialog and once signed in, restore subscriptions and data.)
Edit: In the meanwhile, I tried with the RetryLink, and it seems to work: subscription attempts are caught, giving the opportunity to catch, authenticate and re-subscribe. But I'm not sure this is really a good approach to handle sign out/in. Recommendations on how to handle it are welcome. Here is the updated sandbox.
Original attempt:
Initial rendering:
Rendering after clicking the sign out button and logs showing the steps:
Note: The graphql server is a sample hasura app hosted on Heroku with JWT authentication enabled. The client app has a JWT valid for many years.

How do I continue a conversation after my token has expired?

I am trying to use a conversation reference to continue a conversation with a user within my node bot server. This conversation, I assume, is trying to be resumed after the last API token received has expired. When I try to call continueConversation which is defined in botFrameworkAdapter.ts in the botbuilder library (note, that this is not within a turn, so no message has been received from Teams since the API key has expired), with my service URL as https://smba.trafficmanager.net/uk/ which is what I have stored in my conversation reference, I get an unauthorized error.
After digging into the botbuilder library, I have narrowed it down to the shouldSetToken method within microsoftAppCredentials.js. It would seem the issue is that https://smba.trafficmanager.net/uk/ is not a trusted host name, and as a result the connector does not attempt to retrieve a new token for use.
I can verify that changing the shouldSetToken method to always return true solves my issue, but what is the correct approach to do this which does not involve altering the library?
I've managed to get around this for now with MicrosoftAppCredentials.trustServiceUrl(serviceUrl). If there is a better approach it'd be great to hear it.

iOS9 in-app purchase error code changed for user cancellation?

On iOS8, in my app (which is working fine), if the user is not logged in with their Apple Id, and they attempt an in-app purchase, they get the following Apple alert:
Now, if the user presses "Cancel",in the code, we get an error code 2 with the SKPaymentTransaction. This has the enum code SKErrorPaymentCancelled
On iOS9, in the same situation, we now get error code 0,
Error Domain=SKErrorDomain Code=0 "Cannot connect to iTunes Store"
UserInfo={NSLocalizedDescription=Cannot connect to iTunes Store}
This has enum code SKErrorUnknown, which doesn't seem useful.
Anyone else run into this? The difficult here is in my app UI. If I get an error code, SKErrorPaymentCancelled, I don't present any info to the user as it is clear that the user has explicitly done a cancellation.
With SKErrorUnknown, I can't tell what has gone on, so I present an error alert to the user. Which, if they have explicitly cancelled, is just annoying. Thoughts?
May be :
Your app is enabled only for other location, test user was localized for other - and with this setup does not work. You should enabled the app for USA and created a test user localized in USA and it seems to work (no code change at all). And I think that proves that the code is ok, just the apple sandbox has some problems with non USA test users.
And don't login from settings. When this login form comes from your app, try it.

Azure Notification Hub Register iOS Device Always Returns Unauthorized

Early on in developing an iOS app with Xamarin, another developer and I got push notifications working for it using the Azure Messaging Component. It's a few months later now, and sometime between then and now, the push notifications stopped working. The code is still basically the same as before (which is nearly identical to the example code for the component), it was just moved to its own class for maintainability.
On Hub.UnregisterAllAsync(DeviceToken, error =>, error is:
The operation couldn’t be completed. (NSURLErrorDomain error -1012.)
On Hub.RegisterNativeAsync(DeviceToken, tags, error =>, error is:
URLRequest failed for <NSMutableURLRequest: 0x167dbd80>
{ URL: https://[our namespace].servicebus.windows.net/[our hub name]/Registrations/?$filter=deviceToken+eq+'[long token]'&api-version=2013-04 }
with status code: unauthorized
We tried a new hub, and a new namespace with a new hub, but without luck. I've rolled back the changes we've made since it was working, but with no luck there either. The same error happens on multiple devices, on multiple networks. It never shows any errors in the portal for APNS, so I'm assuming this is something with authenticating to the Hub itself. What is really weird is that a Windows Store app that we wrote to test this registers and receives notifications using the same credentials without any issue. Can anyone point me in the right direction on this? The error messages above aren't very helpful.
It turns out that the test devices all had the automatic date and time synchronization turned off. The iPad I was primarily testing with was only off by about 20 or 30 seconds, so I didn't notice it was off. Another question involving the same thing with a Windows or Windows Phone registration clued me into it, but I can't find the link to it now. Apologies for that, thanks to whoever that was!
Looking at the API, it makes sense why it's so sensitive to this. It uses the date and time to generate the SAS Token, thus the unauthorized response when the time is just a few seconds off.

Resources