Could you please post your startup class? Did you have any add-ons installed. Seems like something changed the status code.
Nothing is installed yet. This is as bare as an Opti site can get. I ran the `dotnet new epicmsempty` and `dotnet-episerver create-cms-database` steps. Added `AddAdminUserRegistration` to my startup and launched the site.
Here's my startup:
public class Startup
{
private readonly IWebHostEnvironment _webHostingEnvironment;
public Startup(IWebHostEnvironment webHostingEnvironment)
{
_webHostingEnvironment = webHostingEnvironment;
}
public void ConfigureServices(IServiceCollection services)
{
if (_webHostingEnvironment.IsDevelopment())
{
//Add development configuration
}
services.AddMvc();
services.AddCms()
.AddCmsAspNetIdentity<ApplicationUser>();
services.ConfigureApplicationCookie(options =>
{
options.LoginPath = "/util/Login";
});
services.AddAdminUserRegistration(opt =>
{
opt.Behavior = EPiServer.Cms.Shell.UI.RegisterAdminUserBehaviors.Enabled;
});
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
app.UseStaticFiles();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapContent();
});
}
}
I tried moving the position of the "AddAdminUserRegistration" around in code, and that didn't seem to make any difference. I see the same behavior when I run from Visual Studio through IIS Express as when I run from `dotnet run`.
I should note, though, that other than the initial redirect, everything appears to work great.
I don't think it matters, but what happens if you register ASP.NET Identity before CMS? Then you shouldn't need to configure the application cookie either:
public void ConfigureServices(IServiceCollection services)
{
services
.AddCmsAspNetIdentity<ApplicationUser>()
.AddCms()
.AddAdminUserRegistration(opt =>
{
opt.Behavior = EPiServer.Cms.Shell.UI.RegisterAdminUserBehaviors.Enabled;
});
}
... and there can always be something that hijacks the first redirect, but in this case there shouldn't be anything. And as you figured out, you can always navigate manually to the view in worst case scenario.
We have created a bug for this https://world.optimizely.com/support/Bug-list/bug/CMS-21815. A fix should hopefully be available in next release. As I suspected, the routing middleware rewrites the redirect to a 404.
Where is the documentation for this?!?! This thread is the only thing on google.
There is no documentation, yet. We did a soft launch and only included it in our release notes a while back. Then we included it in our templates, https://world.optimizely.com/blogs/Johan-Pettersson/Dates/2022/3/new-templates-and-getting-started-experience/, and hope that will help people discover it. What kind of documentation do you think is needed? Because there isn't much to it, other than enable it or not. The options for it are rather self-explanatory.
Hoping people will discover undocumented features isn't really that friendly. Definently not after this big rewrite to .NET 5. When you have great stuff like this, you really have to bring it to the public.
One problem I just can't image I'm the only one having is creating an admin account on a clean DXP setup. There's no mention in the documentation that this has to be done by code, or with this extremly helpful feature. The documentation just says create package, upload and login as administrator. Failing to mention that there's no default account like the old "admin/store".
The feature itself doesn't need that much explanation, but it really really needs to be a part of the documentation to get up and running. That, and the cli "add-admin-user". To me, this feature is much easier to use than the snippet from Quicksilver to intercept the request and add a user if there's none. (https://github.com/episerver/netcore-preview/blob/master/Quicksilver/EPiServer.Reference.Commerce.Site/Infrastructure/UsersInstaller.cs)
I didn't mean we shouldn't document it. But I do believe no one, except maybe new developers, would discover the feature if we don't write articles and/or release notes as well.
It was a long time ago I deployed to a "fresh" DXP, but don't you usually upload a database backup that already have content and users? But yes, we should mention this in the DXP deployment documentation.
Well I would say that you guys should point to what the preferred way is :)
I personally like this approach, not copying bloated stuff from your own computer to integration, and not moving even more bloated data from tests to preprod. This is also a great way to find nasty bugs that breaks the site if there's certain content missing.
Either way, this is a great quality of life improvement if you're not able to run cli against the environment. Or just don't want to.
Note that a lot of our customers do not even use an identity provider that supports user creation. We only ship EPiServer Identity (which is based on ASP.NET Identity) that supports this.
The CLI doesn't work unless you change the firewall configuration in DXP. Not sure we allow that, maybe we do for the integration environment.
So I recently created a blank, new Optimizely CMS 12 site, excited to try the new `AddAdminUserRegistration` feature from this update: https://world.optimizely.com/documentation/Release-Notes/ReleaseNote/?releaseNoteId=CMS-20890
Upon loading the site for the very first time, instead of being wisked to an admin user registration page as expected, I was greeted with a blank 404 page. I spent some time investigating and saw in the logs that the system was trying to take me to the registration page, it was even setting the appropriate Location header. The issue appears to be that the page status code is 404, rather than some redirect status code.
See the log here:
And the response in Firefox's network inspector:
So if you're having issues with this new feature, the work-around (for now) is to just manually go to the /Util/Register URL.