Activities of "okains"

I have just created a new token, fully authenticated, getting a proper 200 back now. Here are the logs for this:

https://drive.google.com/file/d/1BeNMJv2JSxjF68yPGT_v6uYUu3kPqrGG/view?usp=sharing

And the token:

eyJhbGciOiJSUzI1NiIsImtpZCI6Ijk3MTI0OEM5QUQxNjBGQkRBNzA3N0MzMDg4NzY2MkNDMTQxMDRCRUMiLCJ4NXQiOiJseEpJeWEwV0Q3Mm5CM3d3aUhaaXpCUVFTLXciLCJ0eXAiOiJhdCtqd3QifQ.eyJpc3MiOiJodHRwczovL2xvY2FsaG9zdDo0NDM1OS8iLCJleHAiOjE3NTQ0MTE0NzYsImlhdCI6MTcyMjg3NTQ3NiwiYXVkIjoiRVN2MiIsInNjb3BlIjoib3BlbmlkIHByb2ZpbGUgZW1haWwgRVN2MiIsImp0aSI6ImJiNDY0ZGI0LTI1ZDAtNGM1Ny1iOWE0LTJlYzYzYTZiNjY2MyIsInN1YiI6ImExMzY1MWU3LTZjYTEtZTAwNC02ZTM2LTNhMGRlZTZiNzBjOSIsInNlc3Npb25faWQiOiI4M2Y2ZjMxYy1kYjY2LTQ1YmYtODRjNi03ODZiYTMwMDQwNDgiLCJ1bmlxdWVfbmFtZSI6ImFkbWluIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYWRtaW4iLCJnaXZlbl9uYW1lIjoiYWRtaW4iLCJyb2xlIjoiYWRtaW4iLCJlbWFpbCI6ImFkbWluQGFicC5pbyIsImVtYWlsX3ZlcmlmaWVkIjoiRmFsc2UiLCJwaG9uZV9udW1iZXJfdmVyaWZpZWQiOiJGYWxzZSIsIm9pX3Byc3QiOiJFU3YyX1N3YWdnZXIiLCJjbGllbnRfaWQiOiJFU3YyX1N3YWdnZXIiLCJvaV90a25faWQiOiJiMjBiOTkzNS1kYjQzLTM0YzYtNjQ0ZC0zYTE0MzU4ZTUyYzEifQ.NDr7plqxw-I2_9D8s-T9ohsZ1YYiufoXaIYkDWXpzGeiHrfZkdBxXitwkgtfftFNApsiUTgAb2-43o_m48_IrJo74y0L3_PBhn6F-13MFw9ADIf_HTuNPlxhLUq48uTmztNEQUbvTIa6iToUj59iM3azsfHjHe2SqziLSJVNMs_b1DsHTmJB2V9faEuiwVLEJqBDCGL-ohGbFizEL5xfpDLNI1yRf4C-jSqccQ-YC41Ur5xf9Cv1kkNpzSnnfUke8oW0KRT5_xnXJY4FUECe-AaK6UWi0IbbU6PC7O7ER3tSc5BpokrdWl4kFiEklIM9n2mjMvk4HY9fCxfR0Dmang

Will be a day now when this expires, I can re-run this tomorrow and will get a 401. Can send the logs then. Please take a look in the meantime though and if there is anything obvious to you that is wrong let me know. Would like to resolve this as soon as possible.

Thanks,

Karim

OK, great, thank you!

Hi, I can share my full local logs now. I will then clear and run an authenticated request with a new token and share those logs. Will have to wait a day then to share the logs with the 401.

Here are the full logs, maybe there is something you can see in there that can help troubleshoot.

https://drive.google.com/file/d/1BcrCYTkWSM1Uu5fQfoEzdiCfq8L136uq/view?usp=sharing

Thanks,

Karim

what does okay mean? Are you okay with the workaround? Are you okay with giving me the question credit back? Can you be more specific please so I understand the outcome of this ticket?

Thanks,

Karim

I can share anything you like, can you be more specific about what logs you need? What exactly are you looking for in the logs? I am deploying to Azure, so I can turn on logging there?

• ABP Framework version: v8.2
• UI Type: Blazor Web App
• Database System: EF Core (SQL Server)
• Tiered (for MVC) or Auth Server Separated (for Angular): yes
• Exception message and full stack trace:
• Steps to reproduce the issue:

Hi,

Before I upgraded my 7.x project to 8.2 I could generate long lived access tokens ( 1 year ) using the following code in the AuthServerModule:

PreConfigure<OpenIddictServerBuilder>(builder => { builder.SetAccessTokenLifetime(TimeSpan.FromDays(365)); builder.SetIdentityTokenLifetime(TimeSpan.FromDays(365));

});

This code still works, and I get a token in the db that seems to have everything set correctly:

However after about a day the token stops working. Nothing has changed in the db, and the token is of course the same, but for some reason I get a 401 when using the token, whereas for the first day ( could be more or less but seems like about a day ) it works fine:

I noticed that ABP 8.x has upgraded to OpenIddict 5, and I went through all of the migration steps for that, so I looked for anything that changed and I see that there is now the concept of per client token expiration settings. However the global settings supposedly override that ( if client settings are not set explicitly ) and I am not sure how to configure ABP to use the client settings.

Can you provide any insight into this, and suggest some things to try so that I can get this long lived token functionality back?

Thanks,

Karim Ainsworth

Hi, let met provide an update on this. I have a workaround for now.

This is happening with InteractiveAuto rendering, which is the default rendering mode on the ABP Suite generated Blazor Web App. Once the WASM code has finished downloading, and the app is switching from the socket connection to WASM that is when the 'Authorizing...' text is shown and things are rebinding.

At this point I lose the binding to my overridden ABP Components, even though they are in the Client Project, which is the main problem. Also, this WASM download is happening on every route, so this behavior repeats constantly.

So, the workaround is the change the global rendering mode to InteractiveServer and not use WASM at this point, which is fine for me and everything works perfectly. So I will stick with that until I know that the WASM experience has been fixed / improved.

I am OK to close this now, I will go with this workaround on this project.

Can I get credit back for the question?

Thanks,

Karim

Hi,

Just some more info on this. On initial page load everything is fine, binding our control using OnInitializedAsync(). After the 5 second pause, then the Authenticating... message none of the page lifecycle methods are being hit. This happens on every page, so it is not really possible to do any UI work now.

Looking around on Chat GPT for general solutions and seems this might be related to an issue in middleware:

"Additionally, ensure that your authentication service or middleware is configured correctly and doesn't inadvertently trigger a full page reload or component reinitialization. This behavior can often be controlled via configuration settings or by using specific authentication mechanisms that work well with Blazor's SPA nature."

Hopefully this gives you an idea on where to look.

Thanks,

Karim

OK please continue to investigate. Even if that Authorizing call is normal, we are losing the binding of our ABP Custom Components and other page level data binding. That can't be correct. This is making it extremely difficult for us to even do any dev work on the UI.

Hi,

I have given you acces.

Thanks