我正在为ASP.NET MVC 2中的特许经营服务业务构建基于Web的CRM + CMS的第二次迭代。我需要根据用户为该特许经营权分配的角色来控制对每个特许经营服务的访问权限
4个例子:
Receptionist
应该可以为她的“Atlantic Seaboard”特许经营预订服务工作,但不能做任何报告。Technician
应该能够改变服务作业,但不能修改发票。Managers
应该能够对商店内的工作发票应用折扣。Owner
应该可以为他拥有的任何特许经营权提供报告。特许经营级访问控制应该放在Data - Services - Web
层之间的哪个位置?
如果它属于我的控制器,我应该如何最好地实现它?
Roles
class int ID { get; set; } // primary key for Role
string Name { get; set; }
Franchises
类short ID { get; set; } // primary key for Franchise
string Slug { get; set; } // unique key for URL access, eg /{franchise}/{job}
string Name { get; set; }
UserRoles
映射short FranchiseID; // related to franchises table
Guid UserID; // related to Users table
int RoleID; // related to Roles table
DateTime ValidFrom;
DateTime ValidUntil;
[Authorize]
属性如果只涉及一个特许经营权,我可以简单地限制对控制权行动的访问:
[Authorize(Roles="Receptionist, Technician, Manager, Owner")]
public ActionResult CreateJob(Job job)
{
...
}
由于特许经营权不会只是一夜之间出现,或许这是使用ASP.NET MVC 2中新的区域功能的一个强有力的案例?或者这会导致重复的视图?
假设没有使用区域,那么确定访问哪些特许经营数据的最佳方法是什么?我想到了这个:
{franchise}/{controller}/{action}/{id}
或者更好的是在详细信息(...)操作中确定作业的特许经营权并使用[授权]限制用户的操作:
{job}/{id}/{action}/{subaction}
{invoice}/{id}/{action}/{subaction}
如果任何用户可以访问多个特许经营权而不会使用{franchise}参数混淆URL,则更有意义。
赞赏任何意见。
修改:
我在经典ASP中构建了以前的CRM,它运行良好,但是升级时间可以加快工作流程并减少出错的空间。为了正确测试和更好地分离数据和表示,我决定实现Rob Conery的MVC店面系列中的存储库模式。
让JobService
根据可用的过滤器检索任何服务作业是有意义的,例如。 IQueryable<Job> GetJobs();
。但由于作业只能属于一个特许经营,因此像IQueryable<Job> GetJobs(int franchiseID);
这样的函数可能属于FranchiseService
或JobService
。 FranchiseService
应该作为CatalogService
(如在MVC店面中)吗?
答案 0 :(得分:0)
让我试着回答这个问题。我正在玩一个样本应用程序,它触及了上面提到的一些方面。这不是权威的答案,只是经验。
特许经营级别的访问控制应该放在数据 - 服务 - Web层之间吗?
此访问限制应该 渗透到你的应用程序中 两个层次1)数据库2) 应用层。在MVC上下文中我 建议创建一个自定义 授权属性 - 此处理 Web服务之间的安全性 层。我会有这个属性吗 两件事
- 获取用户允许的当前角色(可以从其中获取DB) 存储在用户会话中)
- 执行检查以查看用户是否属于允许的角色列表。 关于数据库,这个 取决于你如何存储 数据,所有特许经营权的一个数据库 或每个特许经营的数据库。在里面 第一种情况有几种限制方式 和设置访问限制 数据到特定的 专利权。
醇>
由于特许经营不只是一夜之间出现,或许这是使用ASP.NET MVC 2中的新区域功能的一个强有力的案例?或者这会导致重复的观点?
我认为应该习惯这些区域 拆分和组功能。如果你 是用区域来分割特许经营权, 这是我看到重复的地方 视图,控制器等发生。重复 通过使用a可以克服视图 自定义视图引擎 覆盖MVC定位你的方式 观点。插头:请参阅我对ASP.NET MVC: customized design per domain
的回答
假设未使用区域,确定访问哪些特许经营数据的最佳方式是什么?
如上所述,你可以 用户会话存储基本 特许经营等信息 用户属于和角色等 分配。我认为我读过的规则 某处沿着某条线 “保护你的行动,而不是你的行动 控制器“
为规范创建路线等 不是例外。例如。在那儿 目前一个商业案例说a 用户可以访问多个 特许?
如何安排服务和存储库?
拥有一组基本服务或基础 包含所有的类 特定所需的信息 特许经营权,如
franchiseId
。 它确实解决的主要问题是 你的服务方法更清洁 没有franchiseId
参数。 但是,存储库可能需要这个 价值,因为你需要的一些点 消除您的数据歧义 请求或存储(假设一个db 所有特许经营权)。但是,你 可以使用IoC克服其中的一部分。
我看到的缺点是 他们总会打电话给 每次你的对象都是数据库 创建(即如果你可以 创建的特许经营清单 在你的应用程序开始你 可用于将您的路线值映射到 获取正确的信息。这个 部分答案是分散的,但是 最重要的是IoC会有所帮助 你解耦了很多依赖。franchise
你需要使用路线 去数据库获取 相应的特许经营权每次都是 您创建一个服务对象。 ( 我可能 自从IoC以来被误认为是这个 容器确实有一些LifeStyle 可以提供帮助的选项 防止这种情况)
希望这会有所帮助..