That code is example code for use in pages that extend a site module. A module will pass the page id and module id to any supporting pages like an edit page and these are helper methods that check that in fact the module exsits on the page and the user has permissions to view or edit depending on the page needs. Like in the blog module we would check that the user has view rights on the ViewPost.aspx page (you never see this in the url because of the friendly url mapping), but on the EditPost.aspx page we would check for edit permissions.

On a free standing .aspx page that is just linked into the menu as a fully qualified url, these helper methods are of no use.

You would have to know from within your page code what roles are allowed to do things and do your own checks

psuedo example:

using mojoPortal.Business.WebHelpers;

if(!WebUser.IsInRoles(smeicolonseparatedstringofallowedroles)) { redirect to access denied;} 

Hope it helps,

Joe

Hi Michael,

Basically those are helpers functions that live in mojoBasePage and those functions are useful for enforcing security in the supporting pages of a module. Supporting pages of a module do expect both a page id and a module id to be passed in.

The helper functions check both the permissions of the page and the module. If the user has edit permssion on the page and the module is contained on the page then the user can edit. Edit permissions on the module are supplemental in that its a way to give edit permissions on a module without giving edit permissions on the whole page. So if the user has either edit permission he can edit.

ViewRoles on the module are also supplemental in that they are a way to prevent a user who has view permissions on a page from seeing a particular module.

From mojoBasePage there is always a PageSettings object named CurrentPage based on the pageid in the request. If the page id is not present it just returns the default page, ie the home page or first page in the site hierarchy. This CurrentPage object is lazy loaded the first time it is access by code and then cached in the httpcontext for the duration of the request processing. But its no use for a hacker to manipulate the params because we do check that the module exists on the page not just if the user has permissions on the page. So all the pages in the menu have a page id and are served from Default.aspx?pageid=x but you don't see this because of the friendly url mappings.

So the reason we only need to pass in the moduleid to those helper functions is because mojoBasePage already knows what the page id is. So that might lead you to think its only checking module permissions but it is always checking both page permissions and module permissions and verifying that the module exist on the page so it can't be manipulated by the url params.

Hope it helps,

Joe