ASP.NET 应用程序服务 - 如何创建新用户帐户？
我一直在研究 ASP.NET 应用程序服务。 我已经成功实现了身份验证服务、配置文件服务和角色服务，能够登录并获取已登录用户的配置文件信息和角色信息。
现在我注意到一个重大缺陷，即我无法弄清楚如何使用应用程序服务内容创建新的用户帐户。 有人知道怎么做吗？
I've been playing around with ASP.NET Application Services. I've implemented the Authentication Service, Profile Service and Role Service successfully, able to log in and get Profile information for the logged in user and Role information.
Now I've noticed a major shortfall in the fact that I can't work out how to create a new user account with the Application Services stuff. Does anybody know how?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
似乎是 应用程序服务 AuthenticationService 仅支持验证现有用户。 您应该允许通过应用程序的其他部分（您自己的 Web 服务或网页）创建用户。
Seems like the Application Services AuthenticationService only supports validating existing users. You should enable creating users through some other part of your application, either your own web service or a web page.
我不确定应用程序服务，但我知道您可以使用会员服务创建新用户。
就像这样：
CreateUser 方法有大约 6 个重写。
I'm not sure about Application Services, but I know that you can create new users with Membership Services.
That's like this:
There are something like 6 overrides for the CreateUser method.
我认为没有多少人不完全理解应用程序服务的作用，因此当他们没有找到通过商店购买的 json 端点公开的完整 ASP.NET 提供程序堆栈时感到沮丧……
应用程序服务是公开公开的。 它们旨在提供身份验证和识别设施。
想想...
您的用户尚未登录。要登录，您必须访问应用程序服务进行身份验证。
正确的？
您真的认为在该端点上公开会员管理 API（例如创建/删除用户）是明智的吗？
在面向公众的 API 上公开管理功能对于适合一种场景提出了巨大的挑战，更不用说能够促进每种场景了，因此也许您可以明白为什么应用程序服务仅公开识别和验证用户所需的内容。
I think not many people are not fully understanding the role of application services and thus feel frustrated when they do not find the full asp.net provider stack exposed over a store bought json endpoint......
Application services are exposed publicly. They are meant to provide an authentication and identification facility.
Think...
Your user is not logged in. To log in you must access application services to authenticate.
Right?
Do you really think that exposing membership management api such as Create/Delete user on that endpoint is wise?
Exposing management functions on a public facing api presents a huge challenge to get right for ONE scenario, much less to capably facilitate every scenario so perhaps you can see why application services exposes only what you need to do identify and authenticate a user.