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)
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.
We are getting the authentication token from the service which gets it from the WSO2. The expiry time that comes along with the token is not consistent. The expiry time sometimes comes less than 3600. For example: 400 or less etc. For this reason, the user is logging out if the expiry time is less. If it brings consistent expiry time i..e 3600 than the user will always log out after 1 hour which is 3600. but due to the inconsistency the user is facing problem.
Check the <TimestampSkew> value in repository/conf/identity/identity.xml.
Make it 0 if it's not already.
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.
Is X-Amz-Expires a required header/parameter? Official documentation is inconsistent and uses it in some examples, while not in others.
If it is not required, what is the default expiration value of a signed request? Does it equal to the maximum possible value for X-Amz-Expires parameter, which is 604800 (seven days)?
The documentation (see above links) talks about X-Amz-Expires parameter only in context of passing signing parameters in a query string. If X-Amz-Expires parameter is required, is it only required for passing signing parametes in query string (as opposed to passing them with Authorization header)?
Update:
Introduction to AWS Security Processes paper, on page 17 says
A request must reach AWS within 15 minutes of the
time stamp in the request. Otherwise, AWS denies the request.
Now what time stamp are we talking about here? My guess is that it is X-Amz-Date. If I am correct, then another question crops up:
How do X-Amz-Date and X-Amz-Expires parameters relate to each other? To me it sounds like request expiration algorithm falls back to 15 mins from X-Amz-Date timestamp, if X-Amz-Expire is not present.
Is X-Amz-Expires a required header/parameter?
X-Amz-Expires is only used with query string authentication, not with the Authorization: header.
There is no default value with query string authentication. It is a required parameter, and the service will reject a request if X-Amz-Algorithm=AWS4-HMAC-SHA256 is present in the query string but X-Amz-Expires=... is not.
<Error>
<Code>AuthorizationQueryParametersError</Code>
...
Now what time stamp are we talking about here?
This refers to X-Amz-Date: when used with the Authorization: header. Because X-Amz-Date: is part of the input to the signing algorithm, a change in the date or time also changes the signature. An otherwise-identical request signed 1 second earlier or later has an entirely different signature. AWS essentially allows your server clock to be wrong by up to 15 minutes without breaking your ability to authenticate requests. It is not a fallback or a default. It is a fixed window.
The X-Amz-Date: of Authorization: header-based requests is compared by AWS to their system time, which is of course synched to UTC, and the request is rejected out if hand if this value is more than 15 minutes skewed from UTC when the request arrives. No other validation related to authentication occurs prior to the time check.
Validation of Query String authentication expiration involves different logic:
X-Amz-Expires must not be a value larger than 604800 or smaller than 0; otherwise the request is immediately denied without further processing, including a message similar to the one above.
X-Amz-Date must not be more than 15 minutes in the future, according to the AWS system clock. The error is Request is not yet valid.
X-Amz-Date must not be more than X-Amz-Expires number of seconds in the past, relative to the AWS system clock, and no 15 minute tolerance applies. The error is Request has expired.
If any of these conditions occur, no further validation is done on the signature, so these messages will not change depending on the validity of the signature. This is checked first.
Also, the leftmost 8 characters of your X-Amz-Date: must match the date portion of your Credential component of the Authorization: header. The date itself has zero tolerance for discrepancy against the credential (so, when signing, don't read your system time twice, else you risk generating an occasional invalid signature around midnight UTC).
Finally, requests do not expire while in the middle of processing. If you send a request using either signing method that is deemed valid when it arrives but would have expired very soon thereafter, it is always allowed to run to completion -- for example, a large S3 download or an EBS snapshot creation request will not start, then fail to continue, because the expiration timer struck while the request had already started on the AWS side. If the action was authorized when requested, then it continues and succeeds as normal.
I apologize if this is a "duh" question. It seems like the answer should be easily googleable, but I haven't found it yet.
I am working on a large Coldfusion application that stores a large amount of session/user data in the Client scope (ie <cfset Client.UserName = "JoshuaC"> ). I did not write this application, and I don't have the luxury of significantly refactoring it.
I've been given the task of setting the Client variables to time out after 72 hours. I'm not entirely sure how to do this. If I had written the application, I would have stored the variables in the Session scope, and then changed the sessiontimeout attribute of the CFAPPLICATION tag. As it is though, I'm not sure if that timeout affects the Client variables, or what their level of persistence is. The way the application works now, the Client variables never time out, and only clearing the user's cookies, or visiting a logout page which sets all the Client-scoped application variables to "", will clear the values.
Of course, I could create some kind of timestamp variable like Client.LastAccessDateTime, and put something in the Application.cfm to clear the client variables if that datetime is more than 72 hours prior to Now(). But there's got to be a better way, right?
Depending whether your are using a datasource or registry as a Client Store you have to set the "Purge data for clients that remain unvisited for 90 days to 3 days (=72 hours) on the
ColdFusion Administrator => Client Variables => Registry
or
Client Variables => NameOfDatabase Page.
If Client Variables are stored as cookies, then you have to adjust the expires period, when setting the cookie.
The Purge Interval on the Client Variables page only controls how often ColdFusion executes a purge operation on your client stores (= seeks for expired Client Variables in order to delete them).
I suppose you are looking for Purge Interval setting, which is configured in CF Administrator at Server Settings > Client Variables page. Default interval is 1 hour 7 min.
EDIT: This setting value is not exactly what you need. I'm sorry, see my comment about purging -- think it is more accurate.