W3C home > Mailing lists > Public > uri@w3.org > July 2007

Re: URI Templates - embedded variables?

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 31 Jul 2007 15:47:40 -0700
Message-Id: <E88AB6C2-10D8-479D-8712-40458056EF43@mnot.net>
Cc: uri@w3.org
To: Lindsay Evans <lindsaye@gmail.com>

Cool. Here's a more fleshed-out example:

A client ("C") wants to access a service at thirdparty.net ("T")  
that, in turn, needs to access the client's user data on a server  
example.org ("S"). To do so, the user needs to authenticate with the  
server S and pass a token to the third party T, which can presented  
to the service in order to obtain scoped access to the user's data.
For clarity, some characters in URIs have not been percent-encoded  
below.

C:	GET /my/pics HTTP/1.1
	Host: thirdparty.net

	T:	GET /user/pictures/ HTTP/1.1
		Host: example.org

	S:	HTTP/1.1 307 Temporary Redirect
		Location: http://example.org/login/;//example.org/user/pictures
		Profile: "http://www.example.com/auth_profile"
		Link-Template: </user/pictures/?t={token}>; rel="token-login"
		Link-Template: <http://example.org/login/;{redir-dest};{partner-id}>;
			      rel="token-source"

Here, the service has told the third party that there are two  
interesting links available; one that shows it how to present a  
token, and another that shows it where to send clients to login  
whilst controlling where they're sent afterwards.

Note that this is completely compatible with existing uses of the  
service; if a client directly contacts it, they'll log in and be  
redirected to the service they originally requested, thanks to the  
Location header.

Now, the third party will use this information to redirect the client  
to the login page, indicating where to include the token once  
authentication is successful;

T:	HTTP/1.1 307 Temporary Redirect
	Location: http://example.org/login/;//thirdparty.net/my/pics/%7Btoken 
%7D;abcdef

C:	GET /login/;//thirdparty.net/my/pics/%7Btoken%7D;abcdef HTTP/1.1
	Host: example.org

S:	HTTP/1.1 200 OK
	Cache-Control: no-cache
	Content-Type: text/html
	
	[ HTML login form ]

[ user-agent gathers authentication credentials]

C:	POST /login/;//thirdparty.net/my/pics/%7Btoken&7D;abcdef HTTP/1.1
	Host: example.org
	Content-Type: application/x-www-url-encoded

	[ URL-encoded credentials ]

After the server has verified the user's credentials, they're  
redirected to the page that the third party indicated, but with the  
token interpolated;

S:	HTTP/1.1 303 See Other
	Location: http://thirdparty.net/my/pics/12345

C:	GET /my/pics/12345 HTTP/1.1
	Host: thirdparty.net

... which in turn is communicated to the server in the format it  
indicated originally;

	T:	GET /user/pictures/?t=12345 HTTP/1.1
		Host: example.org

Given the token, the server now allows access, and sets a cookie (to  
be passed back to the user) that allows further access.

	S:	HTTP/1.1 200 OK
		Cache-Control: private
		Content-Type: application/rss+xml
		Set-Cookie: example_token=[token]
		...

T:	HTTP/1.1 200 OK
	Cache-Control: private
	Content-Type: text/html
	Set-Cookie: example_token=[token]
	...




On 30/07/2007, at 6:58 PM, Lindsay Evans wrote:

>
> Hi Mark,
>
> That's pretty much exactly what I was thinking.
>
> On further thought it seems that the choice between escaping or
> further evaluating the variables would be best left as an option as
> per section 3.3 of the draft, as I can foresee cases where either
> would be appropriate.
>
> On 7/31/07, Mark Nottingham <mnot@mnot.net> wrote:
>> G'day Lindsay,
>>
>> I've got a somewhat similar use case, where I want to pass a template
>> through to another server for processing. So, you might start with
>> something like this;
>>    http://example.com/login?{redirect_to}
>>
>> which gets expanded into something like this;
>>    http://example.com/login?http://other.example.net/target/% 
>> 7btoken%7d
>>
>> which the recipient knows to interpret as containing the template
>>    http://other.example.net/target/{token}
>>
>> Is that along the lines of what you're thinking?
>>
>> Cheers,
>>
>>
>>
>> On 28/07/2007, at 7:32 PM, Lindsay Evans wrote:
>>
>>>
>>> Hi all,
>>>
>>> As I've been building something that makes use of a similar  
>>> concept to
>>> URI Templates, I thought I'd have a crack at building an
>>> implementation in Ruby.
>>>
>>> I've had a look through the list archives, but haven't seen this
>>> mentioned: what is the expected behaviour when a variable is  
>>> embedded
>>> in another variable?
>>>
>>> e.g.
>>> foo = 'xyz'
>>> bar = 'foo={foo}'
>>> template = 'http://example.com/?{bar}'
>>>
>>> At the moment I'm just treating the brackets as literal  
>>> characters and
>>> escaping them:
>>> 'http://example.com/?foo=%7Bfoo%7D'
>>>
>>> but I can imagine the intention in such a case to be for the  
>>> variable
>>> to be evaluated:
>>> 'http://example.com/?foo=xyz'
>>>
>>> --
>>> Lindsay Evans
>>> http://linz.id.au/
>>>
>>>
>>
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>>
>
>
> -- 
> Lindsay Evans
> http://linz.id.au/
>


--
Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 31 July 2007 22:47:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:37 GMT