17713User dependent Resources
- Sep 4, 2011Is it reasonable for a resource to return representations that vary based on the authenticated user? Eg:
We've consider offering both and having my-tasks redirect to the appropriate user= resource. This helps caching, but at the cost of an extra network round trip. It also creates a potential for a direct object reference vulnerability, as I can't trust URIs that come from joe to always say user=joe as joe my get frisky and hand edit it to be user=jane. So I have to check the auth'd user vs the URI parameter anyway. Though I might actually want managers to be able to use the user= form on employees that report up to them.
The my-tasks URI has a huge advantage that it's static, so I can give it to users from static content, or more importantly from external or non-authenticated content where the server that delivers the URI doesn't know I call him joe. The redirect strategy also works for this.
Aside from breaking caching, is there anything wrong with just returning joe's task when he hits my-tasks ? This contemplates a resource that responds to GET with representations that depend on the session token from a cookie or a header. My thoughts on the redirect are that it's STILL a user dependent resource, and that unless I make the user type "joe" in a form, whatever page gives him the user=joe link is probably also user dependent. I suppose I could even save caching by using a rewrite rule instead of a redirect.
- Next post in topic >>