C# 在生产开始或结束时添加授权？

在内部使用ASP.NET/C#网站的制作过程中，首先从身份验证/授权/登录开始，然后从那里开始构建有什么好处吗？或者，最好是按照你想要的方式建立你的网站，有无限的限制，没有登录或者其他什么，然后在生产结束时，在发布之前这样做？这就是我想做的——只需开发网站的功能，不受限制，少担心一件事。但我想确保这种方法不会在以后引起问题

---

在实现ASP.NET身份验证时，只需运行脚本生成必要的表，然后使用WSAT管理用户，然后对现有内容提供限制……应该是……

肯定是的，这是一种实用的方法。你，它说，增加安全性不会给现有项目带来任何问题

---

事实上，在创建用户之前，要确保站点的安全，有很多步骤。另外，您不应该完全依赖WAT进行用户管理。我认为，最好在部署后拥有自己的界面。

您需要事先考虑安全问题。即使您没有开发最终登录屏幕并在开发过程中限制访问，在继续进行“上帝模式”开发之前，您也应该确保您可以验证您的用户并至少在一个屏幕上限制访问。包括：

• 身份验证-窗口、表单等
• 授权/访问控制-角色是否需要或是否需要操作级别检查-例如AzMan
• 如果要使用SiteMap，则需要查看安全性调整，以隐藏用户无权访问的功能（菜单、面包屑等）
• 审计-例如重要数据的变更

---

即使该网站是供内部使用的，用户也不能被信任，您还需要确保您不受SQL注入、XSS等的影响。

您的方法听起来可能更快，但在以下方面存在架构缺陷：

1-缺少与每页/每个方法级别调用的安全对齐

2-不清楚身份验证/授权方面的用例和工作流程

3-在逐渐开发和增加新功能的同时，完全缺乏基于安全性的测试

4-缺乏端到端依赖性-如果需要跨层考虑安全性，您将错过模块依赖性和端到端测试的整个愿景

总的来说，如果您先这样做，那么您可以只建立一个示例用户/pwd/角色，并将其用于站点的所有安全区域，这将足以持续测试和开发应用程序

稍后当你的申请准备就绪；与大量用户/pwd和相关角色一起工作是很好的

---

希望这会有所帮助。

当您有机会完全构建它时，请使用安全性进行构建。谁知道这个应用程序会变成什么样子呢。“在软件可以重用之前，它首先必须是可用的”这意味着安全第一