I am following the details from the recent update to the policy start pack: https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
There appears to be a floor (or so I think) in the process.
I have tried to details the working and non working flow.
Is the 5 minute skew really necessary or am I missing something in my approach.
Thanks
Nigel.
--- Working ---
Request refresh token: refreshTokenIssuedOnDateTime = 13:10
Revoke session: refreshTokensValidFromDateTime = 13:20
Request new refresh token at 13:30:
AssertRefreshTokenIssuedLaterThanValidFromDate correctly throw error as refreshTokensValidFromDateTime (13:20) > refreshTokenIssuedOnDateTime (13:10) (with 5 minute skew)
--- Not working ---
Request refresh token: refreshTokenIssuedOnDateTime = 13:10
Revoke session: refreshTokensValidFromDateTime = 13:12
Request new refresh token at 13:30:
AssertRefreshTokenIssuedLaterThanValidFromDate does NOT throw an error refreshTokensValidFromDateTime (13:12) == refreshTokenIssuedOnDateTime (13:10) (with 5 minute skew)
refreshTokenIssuedOnDateTime = 13:10
Request new refresh token at 15:00:
AssertRefreshTokenIssuedLaterThanValidFromDate does NOT throw an error refreshTokensValidFromDateTime (13:12) < refreshTokenIssuedOnDateTime (13:30) (with 5 minute skew)
refreshTokenIssuedOnDateTime = 15:00
Same as 4 as new refresh tokens always later than refreshTokensValidFromDateTime
To sum up it would appear that if I revoke the session within 5 minutes of the refresh token being issued then I will fall into the non working flow.
Related
I have been studying vesting schedules in blockchain lately. I wanted to test if the implementation of vesting works correctly. First i made a test that has duration of 24 months and cliff duration of 6 months. After testing everything worked correctly, so I decided to create another test but in seconds. Here is the implementation:
it("Should be able to vest gradually (in seconds)", async () => {
// deploy vesting contract
let tokenVesting: TokenVesting = await new TokenVesting__factory(owner).deploy();
await tokenVesting.deployed();
await tokenVesting.initialize();
// send tokens to vesting contract
await expect(saleToken.transfer(tokenVesting.address, 1000))
.to.emit(saleToken, "Transfer")
.withArgs(owner.address, tokenVesting.address, 1000)
const currentBlock = await hh.ethers.provider.getBlock(await hh.ethers.provider.getBlockNumber());
let now: number = currentBlock.timestamp;
let vestingId = "vesting id";
let initiallyReleasablePercentage = 0;
let startTime: number = now + 1; // current time
let duration: number = 10; // 10 seconds
let cliffDuration: number = 4; // 4 seconds
let slicePeriodSeconds = 1; // 1 second
await tokenVesting.createVesting(
vestingId,
saleToken.address,
startTime,
duration,
cliffDuration,
initiallyReleasablePercentage,
slicePeriodSeconds
);
await saleToken.connect(owner).approve(tokenVesting.address, hh.ethers.utils.parseUnits("10", 18));
await tokenVesting.vest(vestingId, owner.address, hh.ethers.utils.parseUnits("10", 18));
/**
* vested amount should be 0 for the next 4 seconds, because cliff duration is 4 seconds
*/
expect(await tokenVesting.getReleasableAmount(tokenVesting.address, vestingId)).to.equal(0);
/**
* go ahead by 5 seconds -> current time is 5 seconds,
* should be able to vest 5 tokens because it reached cliff start time
*/
await hh.ethers.provider.send("evm_increaseTime", [5]);
await hh.ethers.provider.send("evm_mine", []);
expect(await tokenVesting.getReleasableAmount(owner.address, vestingId)).to.be.equal(5);
}
In this code first 10 lines are for deploying vesting contract and sending tokens to it. Then get current time using block.timestamp. Then I create fields that will be used to createVesting. duration is the total duration of a vesting, cliffDuration is cliff time, so time after which we can vest tokens and slicePeriodSeconds is the time that we have to wait after the previous release. Then under the tokenVesting.createVesting I send tokens to the user that will be tested and the amount is 10 and then testing starts.
Here is the problem
First test works fine because the releasable amount is 0. But then when I jump to the future by 5 seconds and test it, the test cracks. It shows that the releasable amount is 7 tokens but it should be 5 because we jumped to the middle of the token vesting period and total amount of tokens is 10.
My thoughts
It got me thinking that in these tests, time does not stop. It is going further. So when I jump by 5 second it logs time before and after creating vesting but when i m trying to getReleasableAmount the time passed and in this function gives me wrong amount of tokens. I don not really know if this is correct it is just my assumption.
Is it possible to somehow stop the time in hardhat testing after evm_increaseTime? When I tested the code but evm_increase_time was in months everything worked and releasable amount was as expected. But trying to test it in seconds when total vesting time is 10 seconds and cliff duration is 4 seconds it is not working as expected.
Has anybody had similar problem or know the solution to that (e.g. stopping the time in hardhat or something else)?
I am using ASP.NET Core 5 Identity with Google as External login.
After I login in Google I get a 500 error when getting back to my application.
The error occurs when accessing the callback url "/signin-google" in my application.
When checking the error details it says it is a 60 seconds timeout error.
How to check of the real error is? I tried to increase the timeout using:
I tried in my application Startup's ConfigureServices method:
services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
.AddGoogle("Google", x => {
x.ClientId = clientId;
x.ClientSecret = clientSecret;
x.RemoteAuthenticationTimeout = TimeSpan.FromSeconds(240);
});
But strangely I get the same 60 seconds timeout error.
How to check of the real error is? I tried to increase the timeout
using:
You need change the time for BackchannelTimeout.
Reference:
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.authentication.remoteauthenticationoptions.backchanneltimeout?view=aspnetcore-5.0
I have three activities. Login,Create Account activity and PostAccountActivity in my app. When Click Create account button I get a crash with the following output on the logcat window
2021-02-03 11:31:47.430 4954-4989/com.example.fauth E/AndroidRuntime: FATAL EXCEPTION: grpc-default-executor-0
Process: com.example.fauth, PID: 4954
java.lang.AssertionError
at io.grpc.internal.DnsNameResolver.getResourceResolver(DnsNameResolver.java:536)
at io.grpc.internal.DnsNameResolver.access$500(DnsNameResolver.java:60)
at io.grpc.internal.DnsNameResolver$1.run(DnsNameResolver.java:211)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)
Go to Firebase console > click your project > cloud firestore > rules.....Edit the timestamp date to a date that you want, probably a future date. Because for me the timestamp date had already passed so I had to adjust to a more future date. Dont forget to change the version of your rules too.
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// This rule allows anyone with your database reference to view, edit,
// and delete all data in your Firestore database. It is useful for getting
// started, but it is configured to expire after 30 days because it
// leaves your app open to attackers. At that time, all client
// requests to your Firestore database will be denied.
//
// Make sure to write security rules for your app before that time, or else
// all client requests to your Firestore database will be denied until you Update
// your rules
match /{document=**} {
allow read, write: if true;
allow read, write: if request.time < timestamp.date(2022, 12, 30);
}
}
}
I am using com.jcraft.jsch version 0.1.55 and connecting to a number of Linux servers, one at a time. Some server connections are successful, while others are not.
Ostensibly the code in the servers is identical. I need to find out why the different behaviour.
Client code. Set up
JSch jsch = new JSch();
Session session = jsch.getSession("username", ip_address, 22);
session.setPassword("password");
session.setConfig("StrictHostKeyChecking","no");
session.connect()
Hangs on calling UserAuthGSSAPIWithMIC.start()
Working flow:
Session.start()
line 22 super.start(session) sets buf[5] = 51
line 25 this.buf.putByte((byte)50) sets buf[5] = 50
flow continues to line 39 this.buf = session.read(this.buf) which returns
and has set buf[5] to 51 forcing the auth to move on the next auth method.
Eventually succeeds using the password method
Broken flow:
Session.start()
super.start() sets buf[5] = 51
this.buf.putByte((byte)50) sets buf[5] = 50
flow continues to line 39 this.buf = session.read(this.buf) which returns
and has set buf[5] to 60 which sends the code to create a new context,
part of which calls oid.equals() which hangs on line 160 -
return this.oid.equals.((Object) ((Oid) other).oid);
There are no log messages in this part of the code, so no information about what the code is doing.
I can make the problem go away by setting session.setConfig("PreferredAuthentications", "password");
I want to know why the code is hanging on the UserAuthGSSAPIWithMIC on some servers but not others. Also how I can get some informative logging information.
We are experiencing a problem where we have incurred all request
Request:
https://maps.googleapis.com/maps/api/directions/json?key=****&units=metricmode=driving&origin=-18.953220736126821,-48.24894517816412&destination=-48.2786408,-18.9218197&
Response:
error_message "You have exceeded your daily request quota for this API."
routes []
status "OVER_QUERY_LIMIT"
Our metrics haven't reported any issues. I am curious how and why these errors are being created.
My account is new and is not in production, we're just testing and ours metrics indicate 22 requests...