Another approach would be to have a property on the start page where you select the login page and then retrieve it by first loading the start page:

var loader = ServiceLocator.Current.GetInstance<IContentLoader>();

var startPage = loader.Get<StartPageData>(ContentReference.StartPage);

var notFoundPage = loader.Get<NotFoundPageData>(startpage.NotFoundPageReference);

This approach would work even if the current page isn't the login page, which might happen if someone would end up on the .aspx file directy and the routing can't resolve the correct page.

Hmm can't edit my post, notFoundPage should of cource be loginPage and so on...

Hi Johan,

And thank you for your answer!

I think the solution you suggested would work if we only had one login page. However, we have many login pages so we need to know which one we're currently on.

How do you decide on which one the user should end up on? Can't you use the same functionality to resolve the login page in you membership provider?

It's difficult to explain using text but I'll make a try.

Our page tree looks something like this:

Main site

--- Sub site 1

------ Login page 1

--- Sub site 2

------ Login page 2

--- Sub site 3

------ Login page 3

So on sub site 1 we have a link to login page 1, on sub site 2 a link to login page 2 and so on.

I'm just worried that I can't assume this code works all the time:

var page = HttpContext.Current.Handler as EPiServer.PageBase;

I've seen examples with MembershipProviders where the ValidateUser-method is set to take three or four arguments but I'd rather avoid going this way if I can.

Use the same logic to find the sub site and then fall back on the start page. Then you know for sure that you have a PageData object. The handler could be something else if you're not routed correctly. Or use HttpContext.Current.Handler as EPiServer.PageBase and if that's result is null you can fall back on the start page.