I have a secret stored in secrets manager and a lambda configured to rotate the secret.
The lambda has all the required permissions to execute correctly and to set up the new password.
I want to keep the new secret in AWSPENDING for 24 hours so that services validating it have time to update.
Is that possible? It seems like a secret rotation tries a couple times and it stops, it doesn't keep on trying for long, and I don't see any parameter to configure this https://awscli.amazonaws.com/v2/documentation/api/latest/reference/secretsmanager/rotate-secret.html
I haven't found any documentation for this, but the secret rotation was tried a couple times, then went to sleep for 27 hours and resumed after that
Related
In my project, there is a configuration value for Oauth that I do not understand:
auth: {
maxIdTokenIatOffsetAllowedInSeconds: 600
},
Based on the document I am reading: https://nice-hill-002425310.azurestaticapps.net/docs/documentation/configuration
For maxIdTokenIatOffsetAllowedInSeconds It says:
The amount of offset allowed between the server creating the token, and the client app receiving the id_token.
What does the offset mean in this case? Is it like a timing unit?
I am assuming it means that each user can only receive one token every 600 seconds?
Can someone explains what does the offset mean? and what maxIdTokenIatOffsetAllowedInSeconds is doing to the token?
The docs you linked to are specifically for the angular-auth-oidc-client library so hopefully that's what you're using. In that case the maxIdTokenIatOffsetAllowedInSeconds is being used to determine how much clock skew is allowed between the issuing server and the consuming browser. In this case, 600 seconds would mean the clocks can be 10 minutes different from one another and the token will still be considered valid.
However, today I came across this issue and any value I pushed in higher than 299 was causing my token to be considered expired. I looked back through the changelog and found a recent-ish PR that added this check and a new configuration value that allows you to ignore it (disableIdTokenValidation).
I am using VM enabled on GCP and would like to increase access token time. By default it is 1 hour.
I a using below command to generate token
query = "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
response = requests.get(query,headers={"Metadata-Flavor": "Google"}).json()
It generates token in the following format and it shows the 'expires_in' seconds. This is remaining time for the token to expire.
{'access_token': 'ya29.c.Ko8BEAjJKLI1bUQBiIj0zZz5hw3TlLjyCoXxKtyslbEnyRj9eUWO0sVdW3512f64ynOoi6laZNnPV
O23nELV5fYhk2epYodI1kXXXXXXXXXXX', 'expires_in': 3035, 'token_type': 'Bearer'}
How can I increase the expires_in parameters either through UI, configuration file or Python API such that token expire as per the defined time?
The purpose of creating long lived token is as I am starting TPU from Google VM using TPU start API and TPU turns on and my machine learning model is trained on the TPU. ML models are quite complex and take more than 10 or 20 hours in many scenarios. After the computations is over on the TPU I want TPU to shut down itself. Then I get the above error which says it cannot authenticated the token as it is expired.
Any example / way to increase the token expiry time or some other way to get rid of this problem.
AFAIK, you can't do that with the metadata server. However, it's possible to generate a short lived token and to extend up to 12h the lifetime of the access token.
You can have a look at this Service Account Credential API. However, you need to update the organisation policy to extend the default (60min) lifetime duration.
I have a frontend in cloud run I want to map to a domain purchased in DoDaddy (breadfree.es) for a demo, but after configuring it in Domain mapping it has taken up to 16 hours and it still does not work. Can you give me any advice? I read it takes from 4 to 8 hours for the dns to propagate, and also that for some it works deleting the records and putting them again (in a link below). Is there any other solution that works in GoDaddy?
Also, it is so strange to me because I have discovered although the domain is not mapped, if I map this service to a subdomain, it is propagated faster. I mapped it with tienda.breadfree.es, and it works, although I prefer it to be map to breadfree.es (tienda means shop in Spanish).
Thanks so much in advance for your help!
Google Cloud Run - Domain Mapping stuck at Certificate Provisioning
In general for Cloud Run (fully managed) it takes 24 hours until the domain is propagated. Even though the SSL certificate can take less than 15 minutes the full process will take up to 24 hours.
This process can take as much as 24 hours because of the certificates and the time needed to be issues and renewed. Indeed, when you map a service to a custom domain like yours (tienda) a managed certificate is automatically issued but for a domain it takes more and it is not automatically issued.
You could try what you posted in the StackOverflow post but you should wait and see after 24 hours if the domain is still not working. Usually if the domain is still not working after 24 hours probably something went wrong in the configuration phase or a step was skipped and I suggest you to open a support ticket in order to check with the Google Team what is the issue.
You can use - https://toolbox.googleapps.com/apps/dig/#A/
This will tell you Time To Live (TTL). For information on TTL check this link (https://support.google.com/a/answer/48090?hl=en)
I followed the instructions here to increase the logout timer of our Jenkins server.
If I run the command below in the script console, it displays the output I'd expect.
import org.kohsuke.stapler.Stapler;
Stapler.getCurrentRequest().getSession().getMaxInactiveInterval() / 60
Result: 14400
However, our users are being automatically logged out after about an hour and a half.
This didn't start occurring until we switched to Active Directory for user logins - but none of our other services that use AD have this problem. That's the only recent change I can think of.
As described in the linked thread in another answer, you also need to set sessionEviction nowadays to keep a user logged in:
For example to keep people logged in for 24 hours and 12 hours of
inactivity:
--sessionTimeout=1440 --sessionEviction=43200
I've been using Google refresh/access token in my in-app purchase verification on server-side.
When refreshing the token, I get a new access token, valid for 3600 secs.
Why can't I just re-ask for a new access token when needed, rather than storing and re-using it?
Why can't I just re-ask for a new access token when needed, rather than storing and re-using it?
Simple answer is you can. Technically speaking you could just ask for a new access token every time you want to make a request. As long as you store your refresh token you will then be able to access the server when ever you need.
I think a better question would be why wouldn't you want to. Well if you are using an application and that application is running for 30 minutes there is really no reason to request a new access token when you can just use the one that was returned to you the first time. You are making an extra round trip to the server with ever request you make if you are also requesting an access token first.
However if you have an application that say runs once every five minutes as a cron job or a windows service well then one could argue that its a pain trying to keep track of it. Actually its not you could just add a date to when it was generated and check the date before using it.
Now google is not going to stop you from requesting a new one every time so feel free. However I cant remember if Google gives you a new access token or if they just return the same one that they generated last time. If they generate a new one every time. Remember that they will all work for an hour so dont leave them laying around.