Activities of "tjinc"

• ABP Framework version: v8.2.2
• UI Type: Angular
• Database System: EF Core
• Tiered (for MVC) or Auth Server Separated (for Angular): yes (separated OpenIdDict auth server)
• Exception message and full stack trace:
• Steps to reproduce the issue:
  • Log in as admin user
  • Create a new user
  • In Administration > Settings > Identity management set the required length to be greater than the default, e.g 20
  • Set the password for the newly created user and generate a random password
• Expected behaviour: The password randomly generated obeys password complexity rules.
• Observed behaviour: The password randomly generated does not obey password complexity rules.

There's a linked issue here

• ABP Framework version: v8.2.2
• UI Type: Angular
• Database System: EF Core
• Tiered (for MVC) or Auth Server Separated (for Angular): yes (separated OpenIdDict auth server)
• Exception message and full stack trace:
• Steps to reproduce the issue:
  • Log in as host admin
  • Create a user with username john.smith@example.com and email john.smith2@example.com
  • Create another user with username john.smith3@example.com and email john.smith@example.com
• Expected behaviour: Error when creating user to say a user already exists with username 'john.smith@example.com'.
• Actual behaviour: User is created successfully, but the second user with username john.smith3@example.com can now no longer log into their account using their email address.

This is very similar to https://abp.io/support/questions/5482/Should-not-be-able-to-create-a-user-with-a-username-equal-to-the-email-address-of-another-user, just with the username and email address 'swapped'. Furthermore, the error message in the solution to the mentioned support is generic, ie "An unknown failure has occurred.", which is not informative.

• ABP Framework version: v7.2.1
• UI Type: Angular
• Database System: EF Core
• Tiered (for MVC) or Auth Server Separated (for Angular): yes (Auth Server Separated - OpenIdDict)
• Exception message and full stack trace:
• Steps to reproduce the issue:
  • Login as a user to generate an active access token and refresh token.
  • Logout to revoke the tokens.
• Expected behaviour: The access token can no longer be used, giving a 401 error if used.
• Actual behaviour: The user is still able to make requests with the revoked access token.

We have tried to write middleware as a workaround for this issue, however ran into problems when dealing with impersonating a tenant/user. Furthermore, the tokens are not revoked if a user is logged in and has "isActive" set false. The suggested behaviour here is that such a user should be logged out and that their tokens are revoked (Note that we are using OpenIdDict tokens).