Fully supporting the Membership API from Orchard CMS?

Topics: Core, Customizing Orchard, Writing modules
Jan 13, 2012 at 12:52 AM

I am curious on best practices.  In the end I will have a fairly heavy business solution on top of the idea of "Membership", we have our own federated single sign on solution in play in ASP.NET Ajax land, and are slowing consdiering the move to Orchard. 

The Goal: Have an Orchard site that can be easily configured to be a "members only" resource, meaning you are greeted with a  locked gate no matter what you try to do until you get logged in.  You can "ring the bell" , and leave "mail" sort to speak.  ...  I want this to be something that can be added on as a module.  From there the ability to register and what types of permissions the site author might give you will have wildly varying effect on the site you see and experience.

So, I am not finding a clear as mud vision for a clean way to replace / participate in the Membership API, especially if I want to stay out side of the core and it needs to be something that can be turned on and off easily.

Surely Orchard isn't doing anything the MembershipAPI cannot for instance, how would you go about wrapping something like that around Orchard?  It took 6 hours and a few tests to master the Membership API and leverage some really great gains, is there something simliar in Orchard I am missing?

I appreciate any advice on approach and, best practices before I start shooting in the dark! 

Thank you much for what you do!  -James

 

Coordinator
Jan 25, 2012 at 7:22 AM

Did you try removing some permissions from the Anonymous role?

Jan 25, 2012 at 11:51 AM
Edited Jan 25, 2012 at 11:52 AM

Unfortunately there's no "View Front End" permission.

However I came up with a simple solution to this, it's in one of my modules, but it's only one file;

 

    public class ShieldingFilterProvider : FilterProvider, IAuthorizationFilter
    {
        private IAuthorizer _authorizer;
        public Localizer T { get; set; }

        public ShieldingFilterProvider(IAuthorizer authorizer)
        {
            _authorizer = authorizer;
            T = NullLocalizer.Instance;
        }

        public void OnAuthorization(AuthorizationContext filterContext)
        {

            if (!(string.Equals(filterContext.ActionDescriptor.ControllerDescriptor.ControllerName, "Account",
                     StringComparison.OrdinalIgnoreCase)
                     && (string.Equals(filterContext.ActionDescriptor.ActionName, "LogOn",
                     StringComparison.OrdinalIgnoreCase) || string.Equals(filterContext.ActionDescriptor.ActionName, "Register",
                     StringComparison.OrdinalIgnoreCase) || string.Equals(filterContext.ActionDescriptor.ActionName, "RequestLostPassword",
                     StringComparison.OrdinalIgnoreCase) || string.Equals(filterContext.ActionDescriptor.ActionName, "RegistrationPending",
                     StringComparison.OrdinalIgnoreCase) || string.Equals(filterContext.ActionDescriptor.ActionName, "ChallengeEmailSent",
                     StringComparison.OrdinalIgnoreCase) || string.Equals(filterContext.ActionDescriptor.ActionName, "ChallengeEmailSuccess",
                     StringComparison.OrdinalIgnoreCase) || string.Equals(filterContext.ActionDescriptor.ActionName, "ChallengeEmailFail",
                     StringComparison.OrdinalIgnoreCase) || string.Equals(filterContext.ActionDescriptor.ActionName, "AccessDenied",
                     StringComparison.OrdinalIgnoreCase)))
                && !_authorizer.Authorize(StandardPermissions.AccessFrontEnd, T("You must log in to view this site")))
            {
                filterContext.Result = new HttpUnauthorizedResult();
            }
                
        }

    }

This basically makes every page redirect you to you LogOn screen, except for those exceptions for registration, lost passwords, etc.

Coordinator
Jan 25, 2012 at 5:11 PM

Actually there *is* a View Front End permission, which have been fixed in 1.x

Jan 25, 2012 at 5:18 PM
sebastienros wrote:

Actually there *is* a View Front End permission, which have been fixed in 1.x

That's pretty cool, missed that change ... I wonder, can we get a View{x}Content in DynamicPermissions too? ;)

Coordinator
Jan 25, 2012 at 5:20 PM

That's something which sould be added in Core and handled in all front end controllers. Then we could create a content item permission module. Someone should suggest it for vNext.

Jan 25, 2012 at 5:22 PM

Quanta already does content item permissions ... it's just waiting for a ViewContent permission :)