Force users to log in

Jimmy Royle

Vote:

We are in the process of upgrading a CMS 11 site to CMS 12.30 and we are making good progress. One thing we would like to do is force users to the CMS log in page if they aren't already logged in when trying to access the site. This would be specifically for DXP Integration and Pre Production environments. We cannot use IP whitelisting for this. The CMS 11 site had this in the web.config and it achieved what I'm describing:

<location path="" xdt:Transform="Insert">
	<system.web>
		<authorization>
			<allow roles="WebEditors,WebAdmins,Administrators"/>
			<deny users="*"/>
		</authorization>
	</system.web>
</location>

Is there anything in CMS 12 that will allow us to achieve the same?

We have been able to achieve this in non Optimizely sites using .net's ConfigureApplicationCookie() in startup, where the user is automatically taken to a specified log in page (Microsoft documentation showing an example). This doesn't seem to work in CMS 12 though, I think maybe because we use AddCmsAspNetIdentity() and this is maybe not compatible?

I'm not sure that would be suitable anyway as I'm not sure the [Authorize] attribute can be applied to specific environments.

Any suggestions would be greatly appreciated.

Thanks

Jimmy

#326002

Edited, Jul 25, 2024 14:09

Mark Stott

Vote:

Just go to the root node in your content tree and remove the "Everyone" role. It's this role that makes the pages publically accessible, once this role is removed, everyone must login.

It's worth adding a middleware to decorate all responses with a "noindex, nofollow" X-Robots-Tag header for the Integration and PreProduction environments, you can target this by injecting IWebHostEnvironment into such a middleware and adding the header to the response.

#326050

Jul 26, 2024 13:18

Jimmy Royle

Vote:

Hi Mark

Thanks for your suggestions. We are currently using the content tree permissions approach, but this causes us some complications with some functionality in our solution (Things like custom scheduled jobs that are unable to read pages for specific tasks). Also this approach means whenever we perform content roll downs from prod, we will need to re-apply the change. That's obviously a very minor problem to have but we were hoping there was a nice clean solution to this problem similar to the CMS 11 one.

Your additional suggestion for the x-robots-tag is something we hadn't thought of. Thanks for that, we're going to implement it.

I'll hold out in the hope there is a programmatical way to force users to the login page on DXP environments in the mean time.

Thanks again

Jimmy

#326052

Jul 26, 2024 14:55

Mark Stott

Vote:

Hello Jimmy,

You could again address this in middleware that operates conditionally on Integration and Preproduction that returns a 401 if the user is not logged in. That way you don't have to adjust your content tree permissions or add Authorization attributes to all of your content.

Regards,
Mark

#326053

Jul 26, 2024 15:26

Stefan Holm Olsen

Vote:

As Mark suggested, you can go for a custom middleware. You could also enforce IP network restrictions, instead of authentication. Cause if you enforce authentication, then it can be hard to test some unauthenticated scenarios before production.

Also ensure you don't block access to health check and warmup endpoints. They "prefer" response codes in the 200's. Otherwise deploying to Preproduction could take a very long time.

#326101

Jul 27, 2024 9:42

Mark Stott - Jul 27, 2024 10:52

Good catch on the health check routes :)

Vincent

Vote:

Hi Jimmy

You can give a try of this module if you don't want to roll out your own one

NuGet Gallery | IPWhitelist 1.0.0-beta.5

#326235

Jul 30, 2024 7:13

Jimmy Royle

Vote:

Thanks for all of your suggestions. We ended up going with the middleware approach.

#326284

Jul 31, 2024 8:07

Mark Stott - Jul 31, 2024 10:32

You're welcome :)