RESTful服务和用户维护-url结构和命令问题

发布于 2024-11-14 20:35:43 字数 456 浏览 3 评论 0原文

我正在设计宁静的服务和要维护的实体之一 - 用户帐户。我在 .NET 中使用会员资格提供程序进行此操作。

这是我所拥有的:

/users/ GET - 返回用户列表

/users/ POST - 可以创建或更新 多个用户(发布用户数组 对象)

如果您更新或创建用户,此帖子并不重要

我的问题是:如何创建更改密码的服务?更改密码与更新用户过程是分开的。我在想这样的事情:

/users/{userName}/password POST - 至 更改用户密码。

但是我必须在这里传递不同的对象? (我使用 JSON)

您对如何布局 URL 有什么建议吗?我真的应该创建另一个对象吗? MembershipProvider 需要更改新旧密码

I'm designing restful service and one of the entities to maintain - user accounts. I'm doing it in .NET and using membership provider.

Here is what I have:

/users/ GET - returns list of users

/users/ POST - can create or update
multiple users (post array of User
objects)

This POST won't matter if you updating or creating user

Problem I have: How do I create service to change password? Changing password is separate from updating users procedure. I'm thinking something like:

/users/{userName}/password POST - to
change user password.

But then I have to pass different object here? (I use JSON)

Do you have any suggestion on how to layout URL? And should I really create another object? MembershipProvider requires old and new password to change

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

孤独患者 2024-11-21 20:35:43

问题在于我们是否将密码本身视为一种资源。

在我的用户数据库中,我将所有密码(加盐和拉伸)存储在自己的表中,因此我可以轻松地将密码作为单独的资源呈现。但仅仅因为你没有那种细粒度的控制并不意味着你不能做同样的事情 - 但我不会考虑为密码实现 GET,最终你需要一个身份验证服务,这应该遵循一些一种协议。

休息服务可以自由地以它希望的方式表示其数据,而不真正考虑底层结构,因此,鉴于此,我认为如果对您的情况有意义的话,您可以自由地将其作为单独的资源来执行。

您可以在用户数据中包含用于更改密码的 uri。客户端必须知道要发送的数据类型(所以是的,您将需要专用的资源类型来处理更改请求),并且应该使用 POST 请求触发 uri。

Well the question has to be whether we see the password as a resource in its own right, or not.

In my user dbs, I store all my passwords (salted and stretched) in their own table, so I can easily present the password as a separate resource. But just because you don't have that fine grained control doesn't mean you can't do the same - but I wouldn't consider implementing a GET for the password, ultimately you need an authentication service for that, which should follow some kind of protocol.

A rest service is free to represent its data however it wishes, with no real regard for the underlying structure so, given that, I think you're free to do it as a separate resource if it makes sense in your case.

You could include in your user data a uri to be used for changing the password. The client would have to know the type of data to send (so yes you will need a dedicated resource type to handle the change request), and that the uri should be triggered with a POST request.

抽个烟儿 2024-11-21 20:35:43

如果我理解您的问题,您希望获得有关与 Uri 布局本身的关系的建议。下面的建议专门与设计可用于更改密码的 Uri 相关。

切勿在 URI 中包含任何明文敏感信息,即使它通过 HTTPS 传输,因为该信息可能会写入服务器上的日志文件,或者更糟糕的是,由分析或监控软件记录。确保敏感信息作为正文的一部分或标头的一部分发送。

以下是为什么使用 RESTfull 服务更改密码可能需要自己的 Uri 的几个注意事项:

  1. 防止在更新用户详细信息时意外更改密码。
  2. 每当此方法发生更改时,您可能需要进行额外的安全审查,因为其中允许匿名用户更改现有用户密码的任何缺陷都将允许该匿名用户劫持该帐户。
  3. 您可能还希望包含其他附加安全功能,例如通知用户其密码已更改并使应用程序的任何 OAuth 令牌问题无效。会员资格提供商很棒,但没有提供这种额外的措施。
  4. 由于它是不同的 Uri,您可以监控其使用情况并将其与 IP 地址相关联,从而允许您检测是否有人试图破坏用户帐户。

您只需将数据合约 PUT 到 https://example.com/users/{id}/password

[DataContract]
public class ChangePassword
{
   [DataMember]
   public string OldPassword { get; set; }

   [DataMember]
   public string NewPassword { get; set; }
}

后者假设您将授权客户端是否可以实际执行此操作。您可能需要查看REST 中的 PUT 与 POST 是否使用 PUT 或 POST。此外,RESTful Web ServicesREST API 设计规则手册 在设计时对我来说非常宝贵RESTfull 服务,包括 Uri 布局。

If I understand your question, you'd like suggestions on how related to the Uri layout itself. The suggestions below is related specifically to designing a Uri that someone can use to change a password.

Never include any sensitive information in the clear in URIs, even if it comes over HTTPS, as that information may be written to log files on the server, or worse, recorded by analytics or monitoring software. Make sure sensitive information is sent as part of the body or part of the header.

Here are a couple of considerations why changing a password with a RESTfull service may require its own Uri:

  1. Prevent accidental changes to a password when updating a user details.
  2. Whenever this method changes, you may need additional security reviews as any defects therein that allows a anonymous user to change the password of an existing user will allow that anonymous user to hijack the account.
  3. You may also want to include other additional security features like notifying a user that their password has changed and invalidate any OAuth tokens issues to applications. The membership provider is great, but doesn't provide this additional measures.
  4. Since it is a different Uri you can monitor its usage and correlate it to IP Addresses allowing you to detect whether someone is trying to compromise a user account.

You can just PUT a data contract to https://example.com/users/{id}/password:

[DataContract]
public class ChangePassword
{
   [DataMember]
   public string OldPassword { get; set; }

   [DataMember]
   public string NewPassword { get; set; }
}

The latter assumes you'll authorize whether the client can actually perform this action. You may want to look at PUT vs POST in REST whether to use PUT or POST. In addition, the book RESTful Web Services and REST API Design Rulebook has been invaluable to me when designing RESTfull services, including Uri layout.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文