API Explorer UI from Razor Pages not rendering after upgrading from .Net 6 to 8

[EmF29]

Hello all,

After upgrading a current project from .Net 6 to 8 and all ServiceStack libraries to 8.1.2 and moving all the Plugins registration to builder.Services.AddPlugin() and calling services.AddServiceStack() in Program.cs, everything seemed to work just fine…

Until I cleared all of my dev browser’s history (Firefox Developer Edition), which then caused the API Explorer UI not to render anymore. It has a JS error and I’m not a JS guy. Have you seen this before or have any pointers on how to solve it?

I’ve also tried with Chrome and same result.

Cheers!

Emilio

[mythz]

It’s trying to reference an external Server.ui object which should be populated on the /ui page.

Can you view the source code of your /ui API Explorer page and see if it contains a window.Server= assignment?

[EmF29]

Thanks mythz for the quick reply.

Your respnse made me think… I wonder if it’s got anything to do with the fact that the website and api are being mounted on a specific URL path rather then on the root.

Anyway on Monday I’ll ask a colleague who is way more versed in User Interface, HTML and JavaScript than me and see what we can find in the source code of the /ui page.

Thanks!

[EmF29]

Hi mythz,

I was able to find the windows.server= assignment and it let me straight to the issue. Thank you so much for the pointer!

I’ll just add some details here in case someone runs into similar problem.

The windows.server= details were as follows:

function loadAuth(auth) {
window.AUTH = !auth || auth.responseStatus ? null : auth
}window.Server={“responseStatus”:{“errorCode”:“Exception”,“message”:“AdminUsersFeature requires AuthFeature”,“stackTrace”:“[MetadataApp: 25-Feb-2024 11:58:49 PM]:\n[REQUEST: {view:locode}]\r\nSystem.Exception: AdminUsersFeature requires AuthFeature\r\n at ServiceStack.AdminUsersFeature.<>c__DisplayClass64_0.b__0(AppMetadata meta) in /home/runner/work/ServiceStack/ServiceStack/ServiceStack/src/ServiceStack/AdminUsersFeature.cs:line 207\r\n at ServiceStack.MetadataUtils.ToAppMetadata(INativeTypesMetadata nativeTypesMetadata, IRequest req) in /home/runner/work/ServiceStack/ServiceStack/ServiceStack/src/ServiceStack/MetadataFeature.cs:line 356\r\n at ServiceStack.Host.ServiceRunner`1.ExecuteAsync(IRequest req, Object instance, TRequest requestDto) in /home/runner/work/ServiceStack/ServiceStack/ServiceStack/src/ServiceStack/Host/ServiceRunner.cs:line 131\r\n”,“errors”:}};

The key error was “AdminUsersFeature requires AuthFeature”.

Even though I had the AuthFeature working fine, the order of execution was the problem. I had the AuthFeature being added after the AdminUsersFeature.

Problems

• The AuthFeature was being added as a Plugin inside Configure(IWebHostBuilder builder).ConfigureAppHost() of Configure.Auth.cs
• While the AdminUsersFeature was being added as a Plugin in .Configure(IWebHostBuilder builder) of Configure.AppHost.cs

Resolution

• I moved the AuthFeature Plugin registration to just before the registration of the AdminUsersFeature and it now works.

Thanks,

Emilio

[EmF29]

Hi mythz,

This is embarrassing. I published the above response while still in Dev mode (Visual Studio 2022).

I just published the application to a Test server and now I’m getting a weird 403 on /ui/lib/app.mjs

I’ve tried configuring the app on both the Root URL and in a specific PathBase, the result is the same.

Any good pointers here?

Thank you!

[mythz]

Sounds like something is corrupting the /ui/lib/app.mjs file in ServiceStack.dll

It’s bizarre why it’s only happening to this file and not the other embedded resource files. The lack of a X-Powered-By HTTP Response Header also suggests this response isn’t being returned by ServiceStack.

Can you try requesting the /admin-ui/lib/app.mjs and /locode/lib/app.mjs for the other built-in UIs to still see if it returns a 403 response as maybe the app.mjs name might be triggering some restriction filter/middleware returning a forbidden response.

[EmF29]

Hi mythz,

I had more time to spend on this today. With your clue below:

for the other built-in UIs to still see if it returns a 403 response as maybe the app.mjs name might be triggering some restriction filter/middleware returning a forbidden response.

I went through the code and found that a PreRequest filter had been setup for most of the built-in UIs. I removed them from the screenshot below and bingo problem solved.

Again, thank you so much for the invaluable help!

Next week I will try to upgrade some .Net 4.7.2 Framework APIs which are on ServiceStack version 6.1… you might hear from me again

It’s 5:10pm here in Brisbane, Australia - time to go and enjoy the weekend. Have a good one.

Cheers,

Emilio

[mythz]

Good to hear you’ve resolved it. I’m in Perth so it’s the weekend for me as well