Hi Dan,
mojoPortal cannot secure your feature for you though it provides some mechanisms to help you implement security.
The Module control itself is hosted within a cms page and we enforce allowed view roles ie the module will not be displayed if the user is not in an allowed view role for both the page and the module instance and the edit links in the ModuleTitle control will not be shown if the user is not in an allowed edit role for the page or module. However the links are just links even if they were shown the security would be enforced in the linked page not by the link itself. So we do provide some security for the module control on the cms page and for the cms page itself but we do not do anything to secure supporting pages for you other than provide some helpful methods.
If you link to a supporting page and pass in the page id and module id and if the supporting page inherits from mojoBasePage we have built in helper functions that can be used to check if the user should be allowed to view or edit but there is nothing that we do automatically for you in supporting pages to enforce security it is up to your own code to do that.
Example of enforcing allowed view roles in a supporting page for the forums:
if (!UserCanViewPage(moduleId, Forum.FeatureGuid))
{
if (!Request.IsAuthenticated)
{
SiteUtils.RedirectToLoginPage(this);
}
else
{
SiteUtils.RedirectToAccessDeniedPage(this);
}
return;
}
Similarly for edit pages that support a feature we have this example from the Blog EditPost page:
if (!UserCanEditModule(moduleId, Blog.FeatureGuid))
{
SiteUtils.RedirectToAccessDeniedPage(this);
return;
}
UserCanViewPage and UserCanEditModule are methods available to you from mojoBasePage
note that you must pass in the module id and the featureGuid for your feature to these methods and the methods ensure that the module exists on the page and is an instance of the specified feature and that the user is in an allowed role.
"In my .ascx file for the feature, I only have a redirect to my first helper .aspx page for the feature in the Page_Load event."
That is not a development pattern I would use, redirecting from page load of a control is a strange arbitrary thing to do that doe snot respect the possibility that other features may also be on the same cms page. None of the included features do anything like that. If a feature needs supporting pages generally we link to it not redirect to it and we pass in the page id and module id so that we can correctly enforce security from code in the supporting page(s).
"In Feature Installation and Configuration, I have the permissions for the feature itself set to Administrators."
That only affects which users can ad the feature to a page it has nothing to do with security enforced on an instance of a feature once it is on a page
To view a module instance on a CMS page a user must be both in an allowed view role for the cms page and an allowed view role for the module instance as defined in ModuleSettings.aspx ie the settings link. They cannot get to the cms page without the page view role and if they can view the page but the module instance is protected by a view role they are not in the module just will not be shown.
A user should be able to edit a feature instance if he is in an allowed edit role from the page settings of the cms page or in an allowed edit role from the module settings. But the actual enforcement of that must be done in code form the edit page that supports the feature.
Hope that helps,
Joe