Re: "important" resources

"Cutler, Roger (RogerCutler)" wrote:
> 
> I really hesitate to enter this debate -- but ...

I don't think you should be concerned about joining the debate with a
technical argument. Obviously tempers flare when people propose that
REST be voted off the island. But I think that our technical discussions
will continue to be quite civil.

> It seems to me that in practical terms, in the business applications with
> which I am familiar, it is actually rather rare to have an "important
> resource" that you want to reuse or reference, because the ability to get at
> the resource must first be authorized.  That is, there is no point in
> keeping a URL that will generate a read on a database if you need to get
> authorized first to access the data.  

I believe that these are orthogonal issues. People send me URIs that are
only accessible through authentication every day. For a starter, there
are those NYT "registration required" URIs. And then various URIs into
member-only W3C pages. Similarly, people often send around filenames to
intranet documents that can only be accessed by people who have logged
into the operating system properly.

The password is very seldom specific to a particular URI. It is specific
rather to what the Web calls a "realm" or Windows might call a "domain".
Therefore you inform your user agent or program of it once and get
access to many resources all at once. Consider the alternative:

"I want you to see this document on the New York Times web site. You'll
need a username and password to get access to it. Once you've got the
username and password, log into the New York Times page and find the
link that says: 'World news'. Then follow that link to a page that says
'Africa'. Then follow a link to a page that says 'Eritrea". Then scroll
down three pages. ..."

Would you rather they sent you the link or the instructions? Keep in
mind that in my example there is an intelligent human reading the
instructions. In the Web services world, there is not. So you need to
send some kind of "script". Consider the security implications of THAT.
On the other hand, the URI is a simple, declarative expression with
known security properties.

I use an example that is visual and web-based because it is easy to
understand. But all of the principles are the same when you are dealing
with purchase orders. You may have one mega-username/password that
allows my SCM software to talk to your SCM software. Once that password
is specified, there is no need to attach it to every reference to a
purchase order.

> ... It seems to me that keeping that
> authorization information (a password, for example) in the URL is a big
> no-no.  

True, because the scope of the username/password information is usually
far greater than the scope of one resource. Leaking one URL could
compromise an entire system. But if you take a disciplined approach,
embedding resource-specific authorization information (cryptographic
authorization, not username/password) into identifiers can be a
legitimate approach to security. In fact I've been convinced that it is
a better model but I do not promote it for fear of tilting at too many
windmills at once.

 * http://www.cap-lore.com/CapTheory/

> ... In practice there is a session state that is carried along, in one
> way or another, that includes this authorization, and keeping a URL for
> anything but the starting point of the process is pretty useless.

I do not see why authorization should be part of the session state. I
think that is a bad idea for the same reason of leakage. But even if you
DO need session state (which is common) and you DO need authorization
information in it (which is uncommon), you can easily do this with
ANOTHER URI pointing to an XML document, which then points to the
service. Then a single URI serves to bootstrap you again.

http://www.server.com/mysessions/mysession_124323

<session>
  <timeout>Friday</timeout>
  <username>blah</username>
  <password>blah</password>
 
<nextstep>http://www.myservice.com/steps/step_8_accept_offer</nextstep>
</session>

(of course you now need to use some security mechanism on THIS URI --
making it unguessable can be cryptographically secure)

This is what REST advocates mean by "hypertext as the engine of
application state." References from one structured object to another are
an incredibly powerful mechanism. This will make sense to anyone who has
worked in a programming language with objects and pointers to objects
(e.g. Java, C++, C#, anything else remotely modern). SOAP 1.1 "best
practice" was to eschew this power!
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/

Received on Monday, 22 July 2002 12:15:59 UTC