- From: Tyler Close <tyler.close@gmail.com>
- Date: Wed, 9 Dec 2009 13:30:14 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-webapps@w3.org
On Wed, Dec 9, 2009 at 10:10 AM, Ian Hickson <ian@hixie.ch> wrote: > On Wed, 9 Dec 2009, Tyler Close wrote: >> On Wed, Dec 9, 2009 at 7:43 AM, Ian Hickson <ian@hixie.ch> wrote: >> > Ok, let's move on to a more complex case. >> > >> > Consider a static resource that is protected by a cookie authentication >> > mechanism. For example, a per-user static feed updated daily on some >> > server by some automated process. The server is accessible on the public >> > Web. The administrator of this service has agreements with numerous >> > trusted sites, let's say a dozen sites, which are allowed to fetch this >> > file using XHR (assuming the user is already logged in). The sites that >> > fetch this file do not require authentication (e.g. one could be my portal >> > page, which is just a static HTML page, without any server-side script). >> > Other sites must not be allowed access to the file. >> > >> > How does one configure the server to handle this case? >> >> Again going with the simplest thing that could possibly work: >> >> Each of the per-user static feeds is referenced by a unique >> unguessable URL of the same format used in the previous example. For >> example, >> >> https://example.com/user123/?s=42tjiyrvnbpoal >> https://example.com/user456/?s=sdfher34nvl34 >> ... >> >> Again, a GET response from such a URL carries the same-origin opt-out >> header. >> >> The user gives this URL only to those services he wants to access the >> feed. For example, you could copy this URL into your personal static >> HTML page that acts as your portal. > > I think asking users to pass around secret tokens is a non-starter. Users pass around secret tokens all the time, they just don't realize that's what they're doing. I assume your statement above is actually meant to say: "I don't want users to see the secret tokens". That's fine. There are a number of ways of doing the GUI such that the user doesn't see the token. We did just such an example for Maciej's calendar scenario. For the above challenge, you specifically asked about the configuration of the server, not the GUI. We can move on to discussing the GUI if you're saying you have no problem with the server configuration. The permission grant and permission exercise phases are analogous to the previous Maciej calendar scenario, so we can reuse those diagrams for the explanation. Just substitute "feed reeder" for "upcoming event" site, and "read feed" for "add event". http://sites.google.com/site/guestxhr/maciej-challenge I'll note that I am providing UMP solutions to challenge problems that meet arbitrary constraints placed on server and GUI. On the other hand, no one has offered a CORS solution to the printing a photo scenario that doesn't resort to using similar secret token techniques. AFAICT, there is agreement that use of secret tokens is a necessary technique, which is far from being a "non-starter". --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Wednesday, 9 December 2009 21:30:47 UTC