Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Enable access for members #4

Open
ed-parry opened this issue Jul 5, 2018 · 5 comments
Open

Feature: Enable access for members #4

ed-parry opened this issue Jul 5, 2018 · 5 comments

Comments

@ed-parry
Copy link

ed-parry commented Jul 5, 2018

Firstly, great package! Proving to be very useful at the moment, but I have a possible feature request if you think it fits with the package concept.

I have a site that I need to lock down and while the Umbraco login works nicely, there are a couple of external testers that don't have Umbraco credentials and they don't really need them. In this case, it'd be great to show a login screen on which the member credentials could work? I know that functionality exists within Umbraco but if the package was able to display a login window hooked up to members it could be a complete solution in one package?

Interested in what you think - happy to try and look at a possible solution if you think it fits with the concept.

@AnthonyCogworks
Copy link
Contributor

Hi Ed

Thanks for your input.

Members in Umbraco are used for public users, where as Umbraco Users is that they have backoffice access.

Having public users able to see a locked down staging site doesnt make sense to me. I guess what you're asking for is some type of privilege which is in between a public Member and a backoffice Umbraco User. However, IMO you can achieve what you want by using the Umbraco User section.

You can create a user which only has access to the content section, while also hiding/denying access to the content tree. That way they can log in, and also have access to the locked site.

I hope that helps.

@ed-parry
Copy link
Author

ed-parry commented Jul 9, 2018

Hi @AnthonyCogworks. Agreed, it's a strange request that we hadn't come across before either, but I'm not sure creating an Umbraco user that lets someone log in, see a blank screen and then have to go to another URL is great UX. The scenario I'm working with is effectively letting a board of directors see a finished site before go-live. The site editors are using Sitelock and it's great, but ultimately a non-tech-savvy director doesn't want to do anything more than they have to, especially having to log into a blank CMS.

I guess it's more niche than I originally thought though, so likely doesn't make sense in a plugin. I'll have a play and see what I can come up with and keep you posted if something comes up/works that could end up fitting in nicely.

@AnthonyCogworks
Copy link
Contributor

I'd give them a full editor account then. If you wanted to deny access to node saving then you can. So they can see but not save.

In our experience, if it's a CEO or director I'd personally sell it to them like this:

"As you can see, this pre-prod/staging site is locked down to editors, so that's why you have an editor account for viewing the site. Don't worry, as your account isn't allowed to save anything".

@mzajkowski
Copy link
Contributor

I see what @ed-parry wants to achieve. It's something like basic authentication, but on the package level. I like this idea / option. Sometimes those CEOs or Directors are non-technical at all and they will loose their minds even within Umbraco, so the easy auth on the frontend might work for them in this case. Correct me if I'm wrong, but if the credentials will live within the package config, we don't need memebership / identity setup?

@callumbwhyte
Copy link

There are some deeper considerations that need to be made when it comes to implementing user and member based auth for Sitelock.

  • A user and a member can in theory have the same username and password - when someone logs in how do we know whether to try and authenticate against a user or a member?

  • Sitelock utilises the Umbraco backoffice session cookie to allow / disallow users. For membership this simply uses ASP.NET identity's session cookie. I don't think this would be too much of a problem.

  • Doing basic auth style authentication with a browser popup is nice UX, but would have to be done in an HTTP Request Handler. This would execute before Umbraco and therefore we wouldn't have any UmbracoContext etc - we'd likely have to construct the context ourselves to utilise the services we need to do this more advanced kind of auth.

Maybe as a first step we could find a way to allow backoffice users to authenticate via basic auth style popups in the browser - perhaps this could be enabled by a config setting. This would be a significantly better UX for the login process for those unaware of Umbraco.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants