Activities of "shorhabelsc"

hi

You can change the GUID way based on your actually case.

There are no restrictions.

You are not answering my question at all. Thanks anyhow

Thanks for the feedback. yet I would like to confirm that the Sequential As String was used because the Guid was stored as char, and so if we decide to use binary format then it won't work well in this case?

Check the docs before asking a question: https://docs.abp.io/en/commercial/latest/ Check the samples to see the basic tasks: https://docs.abp.io/en/commercial/latest/samples/index The exact solution to your question may have been answered before, and please first use the search on the homepage. Provide us with the following info:

• ABP Framework version: v7.3.1
• UI Type: Angular
• Database System: EF Core SQL Server migrating to MySQL
• Tiered (for MVC) or Auth Server Separated (for Angular): yes
• Exception message and full stack trace:
• Steps to reproduce the issue:

Hi,

We have been using ABP Framework for a while with MS SQL Server, therefore we are using the SequentialGuidType.SequentialAtEnd Guid Generator type; however we are migrating to MySql where you are recommending to use SequentialGuidType.SequentialAsString; therefore I have a couple of questions here:

• I presume that you recommendation to use SequentialGuidType.SequentialAsString assumes that Guids will be stored as char(36) in the mysql db. However, I would like to store Guids as binary(16) as it is more efficient across the board, so I assume it does make more sense in this case to use SequentialGuidType.SequentialAsBinary. I appreciate your thoughts on this
• Assuming my proposal above is valid, then as part of our data migration from SQL Server to MySql we will have to convert all guids in our database from SequentialGuidType.SequentialAsString to SequentialGuidType.SequentialAtEnd by flipping the order of the first 6-bytes and the last 10-bytes

Looking forward for your feedback

regards, SG

Hello

I wonder if you have any feedback on the above

regards, Shorhabel

Hi,

Thank you for the feedback.

Microsoft explanation is related to their own implementation in AD B2C service, which is not related to the authenticator app itself not is related to what ABP Code is actually doing. Each server decides how long will it accepts the OTP token; and in their case it seems to be up to 5min,

Generally speaking It is common but not universal to accept, at a given time,

1. the current token,
2. the token from the previous window,
3. the token for the next window. This is done as a partial mitigation for potential clock skew issues on the client that's generating the TOTP codes (e.g. your phone). In practice this means every code is valid for 1m30s, although sites may customize this (with or without changing the window size, which is typically not done because that parameter must be consistent system-wide).

So the question, what is abp server code does in this regard? for how long it would accepts the token?

Regards, Shorhabel