by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Gutemberg Ribeiro
    @galvesribeiro
    Hopefully, ConnectionOpeningAsync() would allow me to set the access token
    let me see :)
    Michał Zegan
    @webczat
    you likely should, just in case, also override ConnectionOpening (non async). also
    Gutemberg Ribeiro
    @galvesribeiro
    ok
    checking how to “inject” an implementation of that
    Michał Zegan
    @webczat
    you don't need a factory. if you start 5 concurrent requests you must have 5 contexts, 5 connections. this would make no sense if you would be using one connection for 5 concurrent requests, that way you totally lose any and all concurrency
    Gutemberg Ribeiro
    @galvesribeiro
    .AddInterceptors() :)
    lets try it :P
    Michał Zegan
    @webczat
    you add this in DbContextOptions, you don't inject this
    I was almost sure I saw these interceptor things and was searching for it in DbContextOptions, hoping they thought of being able to intercept sql connection handling, not only entity operations. I really like the flexibility of all these things
    Gutemberg Ribeiro
    @galvesribeiro
    public class AADTokenInjectorDbInterceptor : DbConnectionInterceptor
        {
            private static readonly string[] _scopes = new[] { "https://database.windows.net/.default" };
            private readonly TokenCredential _credentials;
            private AccessToken _accessToken;
    
            public AADTokenInjectorDbInterceptor(TokenCredential credentials)
            {
                this._credentials = credentials;
            }
    
            public override async Task<InterceptionResult> ConnectionOpeningAsync(
                DbConnection connection,
                ConnectionEventData eventData,
                InterceptionResult result,
                CancellationToken cancellationToken = default)
            {
                await this.RefreshToken();
                var sqlConnection = (SqlConnection)connection;
                sqlConnection.AccessToken = this._accessToken.Token;
                return result;
            }
    
            private async ValueTask RefreshToken()
            {
                if (this._accessToken.ExpiresOn != default &&
                    DateTimeOffset.UtcNow < this._accessToken.ExpiresOn)
                {
                    return;
                }
    
                this._accessToken = await this._credentials.GetTokenAsync(
                    new TokenRequestContext(_scopes),
                    CancellationToken.None
                );
            }
        }
    lets see how it works :)
    Michał Zegan
    @webczat
    I'd use this thing that manages automatic token refresh
    Gutemberg Ribeiro
    @galvesribeiro
    That thing only works when running on azure
    this one I’m using works on both cases and is using the latest packages Azure.Identity which I use for other services that support it on Azure
    Michał Zegan
    @webczat
    so I'd still expose that as a nice service.
    Gutemberg Ribeiro
    @galvesribeiro
    and that one doesn’t do refresh, it has a an internal lock and a ConcurrentDictionary
    already checked their code
    Michał Zegan
    @webczat
    unless you cannot get a service provider when configuring db context.
    Gutemberg Ribeiro
    @galvesribeiro
    not much different than what I have
    And no, the interceptor is not going thru DI
    you have to new it up
    (yeah, freaking retard)
    Michał Zegan
    @webczat
    but you construct it
    if you have access to service provider you can resolve them and pass
    or pass the provider
    so it depends. AddDbContext, when used directly, gives you a way to get service provider.
    Gutemberg Ribeiro
    @galvesribeiro
    u are right
    just found the override
    Michał Zegan
    @webczat
    and then you can use it when configuring DbContextOptions. so in turn you could use it when newing the interceptor or you could register interceptor as service and use it by resolving it's instance from service provider
    Gutemberg Ribeiro
    @galvesribeiro
    yeah make sense, will do that
    Michał Zegan
    @webczat
    probably the latter is better. you are responsible for newing it, not EF core, so if you'd resolve it from di instead, your win.
    Gutemberg Ribeiro
    @galvesribeiro
    yeah
    just need to first make sure the interceptor approach will work :P
    Michał Zegan
    @webczat
    should. you can see
    Gutemberg Ribeiro
    @galvesribeiro
    services.AddDbContext<PagoLivreIdentityDbContext>((sp, options) =>
                    options.UseSqlServer(identityConnectionString, sql => sql.MigrationsAssembly(migrationsAssembly))
                        .AddInterceptors(sp.GetRequiredService<AADTokenInjectorDbInterceptor>()));
    :)
    Michał Zegan
    @webczat
    mhm
    works?
    Gutemberg Ribeiro
    @galvesribeiro
    changing the other stuff that was messed, 1m
    Gutemberg Ribeiro
    @galvesribeiro
    @webczat it worked flawlesly :)
    thanks man!
    now I don’t need the inherited/custom context and have the async acquisition of the access token
    Xiang Jie
    @chuaxiangjie
    i would like to know where is access token stored for aspnet core application? From the documentation, it's stored in authetication properties, what exactly are they? Are they related to browser cookies?
    Subhasis180689
    @Subhasis180689
    I deployed my identity service in AKS and added an ingress controller for that. I created internal DNS for it and added SSL termination for it. Now when anyother service calls the identity service i am getting below error. "Issuer name does not match authority:" with http url. where as i have https endpoint for it
    João Pedro Antunes
    @joaoantunes
    Hi everyone! I've been testing IdentityServer4 and making the prototypes. I'm on the second one "Interactive Applications with ASP.NET Core" so far so good, but when I tried to make the "Further Further Experiments" I was not able to get the rest of the Claims of the Users.
    On IdentityServer project config I've added: "new IdentityResources.Email" to the Resources. On Clients I've added "IdentityServerConstants.StandardScopes.Email" to Allowed Scopes. And at last I added to the MVC Client application on AddOpenIdConnect this line: options.Scope.Add("email");
    But when I retrieve the token the MVC page is not presenting more claims, just the defaults. Am I missing something?
    João Pedro Antunes
    @joaoantunes
    from what I've debug, the scopes are presented on the "token", but how can I get the claims? Do I need to map certain claims to a certain scope?
    João Pedro Antunes
    @joaoantunes
    Maybe what I am missing is adding "IProfileService" that adds those email claims as User claims?