Activities of "hra"

Hi @ismcagdas, while putting together issue details, it is no longer reproducing. Very odd. I will close this ticket, and raise an issue via github if I can figure out repro steps.

Nevermind - offending change found!

An update to @types/lodash - version 4.14.187 published Nov 1, 2022 caused the breakage. It forced a dependency on TypeScript 4.1 functionality

https://github.com/DefinitelyTyped/DefinitelyTyped/issues/63022

Clarification for @KPCS, @musa.demir,

it appears this "only honor the newest password reset code" was only implement 3 months ago (after this thread was opened).

https://github.com/aspnetzero/aspnet-zero-core/issues/4487

Hi,

Sorry to awaken this old thread - however it is the most sensible place to discuss the behavior of AspNetZero today.

There is a comment above, "the next action they take should trigger a permission check which would direct them away" - this is incorrect as of version 10. I just tested this now - a user account (using Token auth) which is disabled by an admin while that user is logged in - will experience no redirects or errors. The "disabled" account will continue to function, fully authorised - until they voluntarily log out, or expire their token.

Is this the intended behavior of ANZ today? If so, I feel it should be recorded as a bug, as an admin who "disables" a user account, intends to do so to prevent that user from accessing the system. If they need to call them up and ask "could you please log out so you cannot get back in?" then the system is flawed. Note: Requesting the browser to discard the token is likely an insecure solution - as a clever user could reinstate the token on their site

So, 2 questions:

1. Is it intended that "disabled" accounts require the effected user to invalidate their token (either through logout, or expiration)?
2. If so, whats the recommended template code to fix this?
   1. note: the above suggestion - throwing an exception during token validation - or even returning false, generates a 302 on the client which doesnt explain this is a "user account disabled" scenario for my API clients (mobile apps)
3. If there is a technical reason why this code should not be integrated into the base product (such as performance concerns) - please explain

Thanks,

Hi,

Thanks for the offer - interestingly enough, as I have written more infrastructure to support multiple databases (see my other post about how to integration test 2 different database schemas in the same in-memory db file, with some shared entities) - the issue has now gone away. (yay).

Not wanting to derail the subject too much - I have noticed that UnitOfWorkManager.Current appears to be null within all unit tests. Is this not set up by the Abp test base classes somewhere by default? Or are we supposed to do this ourselves?

This would imply that none of the existing tests call methods which use the UnitOfWorkManager - which is surprising - perhaps I'm wrong... but it's definitely null for me - which is breaking some tests.

Hi @ismcagdas - this isn't a question - I have posed a problem, and the solution in the one post - in case anybody else runs into this requirement. I probably should have clicked "close" when I posted it. Thanks - closing now.

Hi,

It would take a while to see if I could get clearance for this. However, I know I could set up a Teams video session with you, and show you the issue / let you drive a debug session?

Thanks

Hi,

For anyone who is interested, we have been operating with Managed Identity for a while - where the AbpDbContext obtains the Token within its constructor - however, recently we have started adding unit tests - and because the database is mocked with sqlite - this becomes a bit messy because it needs to know whether its running within unit tests or not.

This is what we came up with, which is far cleaner anyway:

public class AzureSqlConnectionTokenInjector : DbConnectionInterceptor
{
    private AzureServiceTokenProvider _tokenProvider;

    public AzureSqlConnectionTokenInjector()
    {
        _tokenProvider = new AzureServiceTokenProvider();
    }

    protected virtual async Task EnsureAccessToken(DbConnection connection)
    {
        if (connection is SqlConnection sqlConnection
            && connection.ConnectionString.ToUpper().Contains("DATABASE.WINDOWS.NET")
            && string.IsNullOrWhiteSpace(sqlConnection.AccessToken))
            sqlConnection.AccessToken = await _tokenProvider.GetAccessTokenAsync("https://database.windows.net/");
    }

    public override InterceptionResult ConnectionOpening(DbConnection connection, ConnectionEventData eventData, InterceptionResult result)
    {
        EnsureAccessToken(connection).Wait();

        return base.ConnectionOpening(connection, eventData, result);
    }

    public override async ValueTask<InterceptionResult> ConnectionOpeningAsync(DbConnection connection, ConnectionEventData eventData, InterceptionResult result, CancellationToken cancellationToken = default)
    {
        await EnsureAccessToken(connection);

        return await base.ConnectionOpeningAsync(connection, eventData, result, cancellationToken);
    }
}

Then use this in your 'DbContextConfigurer' class:

public static class MyDbContextConfigurer
{
    public static void Configure(DbContextOptionsBuilder<MyDbContext> builder, string connectionString)
    {
        builder.UseSqlServer(connectionString)
            .AddInterceptors(new AzureSqlConnectionTokenInjector());
    }

    public static void Configure(DbContextOptionsBuilder<MyDbContext> builder, DbConnection connection)
    {
        builder.UseSqlServer(connection);
    }
}

Hi @sedulen,

I had similar issues suppressing this logging. Finally I found configuring it in code during creation of the WebHost worked (in my Web.Host project)

Here's mine...

public static IWebHostBuilder CreateWebHostBuilder(string[] args)
{
    return new WebHostBuilder()
        .UseKestrel(opt =>
        {
            opt.AddServerHeader = false;
            opt.Limits.MaxRequestLineSize = 16 * 1024;
        })
        .UseContentRoot(Directory.GetCurrentDirectory())
        .UseIIS()
        .UseIISIntegration()
        .ConfigureLogging(logging =>
        {
            logging.AddFilter("Microsoft.AspNetCore.SignalR", LogLevel.Warning);
            logging.AddFilter("Microsoft.AspNetCore.Http.Connections", LogLevel.Warning);
            logging.AddFilter("Microsoft.AspNetCore.Hosting.Diagnostics", LogLevel.Warning);
            logging.AddFilter("Microsoft.AspNetCore.Routing.EndpointMiddleware", LogLevel.Warning);
            logging.AddFilter("Abp.AspNetCore.SignalR.Hubs.AbpCommonHub", LogLevel.Warning);
            logging.AddFilter("Microsoft.AspNetCore.Mvc.Infrastructure.ObjectResultExecutor", LogLevel.Warning);
            logging.AddFilter("Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler", LogLevel.Warning);
            logging.AddFilter("Microsoft.AspNetCore.Cors.Infrastructure.CorsService", LogLevel.Warning);
        })
        .UseStartup<Startup>();
}

I've had this same issue, with a console app that is loading the Abp modules then accessing tenant settings. I noticed that the truncation occurs every single time, only for encrypted values.

HTH