We have an Identity Server cluster environment with two nodes. It was working without any issue for a long time but last few days OAuth2 validation failing for few users. Two OAuth tokens generated within few seconds and calls are executing with the invalid token (first token). So all the calls failing with "Invalid Access Token or Client Id" error. We have also rebooted Identity Server still same behavior. Token validation is working if one node is removed from the cluster. It will continue to work till next token generation. I am thinking it could be the issue with some cache in Identity Server. Is there a way to clear cache in Identity Server.
Sorry for the lengthy post...
Caches are cleared when you restart nodes, so I don't think this is a caching issue.
I can't say a reason for sure either, but I suspect the clocks of these nodes. Are you sure both servers' clocks are synced? I believe this can happen if the token validation node has a different time than the token generated node.
Just a thought. Make sure falling back from daylight saving time didn't affect just one node in a different way.
Related
We are using Google Ads API and we wanted to validate the Refresh token programmatically, as using a incorrect refresh token or expired refresh token is taking lot of time before giving an exception(60 mins approx or even more) and hence causing a 504 TIMEOUT. Also there is a limitation on number of refresh token that we can create which is at max 50 refresh token at a time and if we create new 51st refresh token then the oldest one will expire. And hence chances of getting into this issue is more likely so we wanted to know if there is some API via which we can validate and then take appropriate actions instead of direct calling Google Ads API and getting into TIMEOUT ISSUE.
We also reached out to Google ads forum for this requirement and suggested to reach out GCP support ref link to Question asked: https://groups.google.com/g/adwords-api/c/tqOdXsnL5NI
We tried calling listaccessiblecustomers .
And we were expecting to get some invalid Exception in some ms or some secs so that we can log it for Error notification to our customers instead, after calling the API the call got stuck for almost 61 mins and then 504 TIMEOUT occurred.
You really need to post your code. You said you tried calling the listaccessiblecustomers service, but how? Are you using the client libraries? If so, what language are you even using?
You need to put in a bit of effort if you need some help. Remember, we can't see what you see on the screen in front of you.
I have a django application that routinely injects messages into an Azure service bus. I am receiving intermittent errors indicating that its messages are unauthorized. I would say that 95% of messages are successfully authorized, with about 5% unauthorized).
I have not changed anything in months related to access (shared access signatures, access keys etc) to the service bus, and I have validated that my python code is still using all the correct values (service bus namespace, topic, access key, etc).
Despite this, I am receiving intermittent errors related to having an invalid authorization token signature:
"AzureHttpError('SubCode=40103: Invalid authorization token signature',)`
How can I correct this, and how can I find out the cause?
From what I can see here in the documentation, the token is generated using a few things:
SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>
You said you've checked the access key, so maybe you should check is your time on your server/computer/device has a correct and stable clock.
For debugging you can just write a log before the service bus call to print the current timestamp of your server and work out whether it is correct.
I want to change the default failure message in Alexa, Sorry, I'm having trouble accessing your {} skill right now.
You cannot change that prompt but you can code to avoid that as much as possible. The error happens when Alexa is not able to get a valid response from your skill endpoint. There can be multiple reasons to that as mentioned here
1. Your endpoint is giving an invalid response
This can be due to the errors/exceptions happening in your endpoint code. You can make sure that error/exceptions don't occur and if they occur, thre is code to catch them and provide a valid response back to Alexa, with an error message of your choice.
2. Your endpoint availability
Make sure that your endpoints are available all the time if you have configured them as an endpoint. This is pretty much guaranteed if you are using Lambda endpoints. But if you are your own hosted web service endpoint, then you must put in all the measures to keep it available for Alexa to communicate with it.
3. Your endpoint response time
Make sure that your endpoint gives back the response within the time period that Alexa expects it to get(guess its 10 seconds). Also make sure if you are using Lambda functions, you have configured them with reasonable execution time to avoid timeout errors.
If you cover the exception/error/availability scenarios well then you can avoid the default error message as much as possible.
I am using Wso2 API Manager 1.8. I have created some apis in it, and subscribed it to an application. I Want to make the token expire time to infinte , means never expire token. I have gone through the tutorial given in wso2 site and done following changes.
refered link : Changing the default token expiration time
I have changed ApplicationAccessTokenDefaultValidityPeriod to -1 . Rest remains same. And I created new application to get the changes, Now get long integer value 9223372036854452224 ie 106751991 days) as expire time. And working fine .
Then I changed the system date to next day check whether the expire not set to zero. But my token expire time chages to 3600000 milliseconds, How this happens, even if the time reduces this much change never expecting.
I have chages the default H2 database to mysql and done same thing with this.
Then I noticed that when the day changes,the token expire time reduces from 9223372036854452224 to 3600000 milliseconds means 1hr of expire time, which is default time. Actually it have 106751991 days expire time. How this happening ?
Please help. How can I solve this problem
Set token validity time to -1 (minus one) - that means never expires (also, see if that is the value that you have in API Store on Subscriptions tab)
I had code that was working that would create a new platform application for every message that went out. I thought that was wasteful so I tried to change the code to use list_platform_applications to get available applications and reuse the one that has the proper name (part of the PlatformApplicationArn).
This will work for several messages in a row when suddenly I'll get this error from CreatePlatformApplication:
{"Error":{"Code":"InvalidParameter","Message":"Invalid parameter: This
endpoint is already registered with a different
token.","Type":"Sender"},"RequestId":"06bd3443-598e-5c06-9f5c-7f84349ea067"}
That doesn't even make sense. I'm creating an endpoint. I didn't pass one in. Is it really complaining about the endpoint it's returning.
According to the Amazon documentation:
"The CreatePlatformEndpoint action is idempotent, so if the requester
already owns an endpoint with the same device token and attributes,
that endpoint's ARN is returned without creating a new endpoint."
So it seems to me, if there's an appropriate one it will be returned. Otherwise, create a brand new fresh one.
Am I missing something?
Oh darn. I think I found the reason for this behavior. After facing this issue, I made sure that each token was only uploaded once to AWS SNS. When testing this, I realized that nevertheless I ended up with multiple endpoints with the same token - huh???
It turned out that these duplicated tokens resulted from outdated tokens being uploaded to AWS SNS. After creating an endpoint using an outdated token, SNS would automagically revive the endpoint by updating it with the current device token (which afaik is delivered back from GCM as a canonical ID once you try to send push messages to outdated tokens).
So e.g. uploading these (made-up) tokens and custom data
APA9...YFDw, {original_token: APA9...YFDw}
APA9...XaSd, {original_token: APA9...XaSd} <-- Assume this token is outdated
APA9...sVQa, {original_token: APA9...sVQa}
might result in something like this - i.e. different endpoints with identical tokens:
APA9...YFDw, {original_token: APA9...YFDw}, arn:aws:sns:eu-west-1:4711:endpoint/GCM/myapp/daf64...5c204
APA9...YFDw, {original_token: APA9...XaSd}, arn:aws:sns:eu-west-1:4711:endpoint/GCM/myapp/a980f...e3c82 <-- Duplicate token!
APA9...sVQa, {original_token: APA9...sVQa}, arn:aws:sns:eu-west-1:4711:endpoint/GCM/myapp/14777...7d9ff
This scenario in turn seems to lead to above error on subsequent attempts to create endpoints using outdated tokens. On the hand, it seems correct that subsequent requests fail. On the other hand, intuitively I have the gut-feeling that the duplication of tokens that is taking place seems wrong, or at least difficult to handle. Maybe once SNS discovers that a token is outdated and needs to be changed, it could first check if there is already another endpoint existent with the same token...
I will research on this a bit more and see if I can find a way to handle this properly.
Cheers
Had the same issue, with the device reporting one token (outdated according to GCM) and the SNS retrieving/storing another.
We solved it by clearing the app cache on the device and reopening the app (which in our case, re-registered the device on the gcm service), generating the same token (not outdated) that SNS was attempting to push to.