我正在尝试构建一个内部网,成千上万的员工可以在该网站上创建,编辑和发布文档。
这些文档相当简单(可能是一个富文本字段和一些其他更简单的字段)。
我想将它们视为Umbraco后端文档(而不是在单独的SQL表中说明数据),因此它们可以包含在部分视图中。
还会有其他更复杂的文档,但这些文档将由较少数量的后端用户管理,所以没关系。
我认为将数以千计的员工视为用户并不正确,因为我读过这会导致性能问题。
因此,在放弃之前,我最后的想法 - 由其他人建议 - 是将它们创建为成员,创建一些包含表单的前端页面,然后他们将这些表单提交给新的控制器,可以检查其成员资格并使用API来创建,编辑和/或发布提交的文档,
他们应该只能编辑自己创建的文档,因此控制器需要知道登录成员是谁(并将其与我将作为创建者存储在所有文档上的成员身份ID进行比较)。
很抱歉提出这么多问题,非常感谢任何可以提供帮助的人。
答案 0 :(得分:1)
Ad.1。检查 ContentService 文档(https://our.umbraco.org/documentation/reference/management/services/contentservice),然后使用它来创建从前端到Umbraco文档的新内容节点。您还可以检查 Umbraco Rest API (https://our.umbraco.org/documentation/implementation/Rest-Api/),但它仍然在v1.0.0之前,因此可能会导致一些问题(尤其是安全性问题)。我在这里写了一篇关于使用API的文章:http://24days.in/umbraco/2015/umbraco-rest-api/。
Ad.2。您可以这样做,但它不是推荐的解决方案。 MVC应用程序默认创建为WAP(Web应用程序项目),所有* .cs文件不仅编译来自App_Code目录。如果您有一个典型的WebSite项目,那么从架构角度来看,将业务逻辑与网站/ Umbraco实例分开并将其放在单独的DLL中会更好。顺便说一句。你为什么害怕部署? :)
Ad.3。当然! Umbraco使用ASP.NET Identity,因此可以扩展为使用任何自定义OAuth提供程序。甚至已经为我们创建了几个。检查:https://our.umbraco.org/Documentation/Reference/Security/和https://github.com/umbraco/UmbracoIdentityExtensions。这是为访问Umbraco Backoffice而描述的,但也有允许对成员使用Active Directory登录的包(例如https://our.umbraco.org/projects/developer-tools/active-directory-providers/)。
快乐的编码,我希望我帮助过!