[whatwg] AppCache can't serve different contents for different users at the same URL

[Ian Hickson]

On Tue, 14 Jul 2009, Aaron Whyte wrote:
>
> Most apps provide different contents for the same uncacheable main-page 
> URL, depending on the identity of the user, which is typically stored in 
> a cookie and read by the server.
>
> However, the HTML5 AppCache spec doesn't allow cookies to influence the 
> choice of AppCaches or the contents of a response returned by the cache.
> 
> This makes it a lot harder, but not impossible, for developers of 
> existing apps to start using AppCache, while still supporting multiple 
> users per browser or browser profile.
> 
> Without changing the user-visible URL structure of an app, developers might
> support multiple users, by replacing their server-generated user-specific
> main page, with a generic cacheable JS app that does this:
>
> 1) Establish the user's identity using a cookie, or a database record, 
> or a session key-value store.
>
> 2) If the user can be identified, load the user-specific resources (JS, 
> CSS, data, etc.) from the network and/or local storage, possibly 
> including a separate AppCache with user-specific or fingerprint-specific 
> URLs. Otherwise, load the unknown-user version or a login page.
> 
> That'd be a complete restructuring of the main page, but it's possible.  
> I suspect that this is the model the AppCache was designed to support.
> 
> A more radical change to existing apps, and app design in general, would 
> be to include account-identifying information in the user-visible URL.  
> The main page could redirect users to their user-specific page or the 
> unknown-user page.

On Tue, 14 Jul 2009, Adam de Boor wrote:
>
> I guess in the double-AppCache model, where there's a generic cached 
> redirect page, one could make it so all user-specific accesses use a URL 
> with a user-specific prefix, so it can prefix-match against an entry in 
> the NETWORK section of the generic cached app manifest.
>
> still, given how many apps on the web identify the user using an ID in a 
> cookie, it'd be nice if apps wanting to use AppCache didn't have to go 
> through these gyrations.

On Wed, 22 Jul 2009, Anne van Kesteren wrote:
> 
> Why not? I cannot find anything like that in the specification. It seems 
> to me that the generic fetching algorithm is used which does not forbid 
> sending cookies and even explicitly calls out setting them.

On Wed, 22 Jul 2009, Drew Wilson wrote:
>
> Not sure what you are suggesting, Anne - it sounds like they want to tie 
> the AppCache to a specific cookie/value combination, which I don't 
> believe is supported by the current spec.

On Wed, 22 Jul 2009, Anne van Kesteren wrote:
> 
> Well, as far as I can tell cookies are part of the request to the 
> manifest file so you could serve up a different one from the server 
> based on cookie data.
> 
> Is the problem supporting multiple users completely client-side? I can 
> see how that might not work very well.

On Wed, 22 Jul 2009, Drew Wilson wrote:
> 
> That's an interesting idea (send down a different manifest), although I 
> don't see how you'd leverage that technique to support two different 
> users/manifests and use the appropriate app cache depending on which 
> user is logged in.
> 
> I think this boils down to "the Gears 'requiredCookie' attribute was 
> really useful".

On Wed, 22 Jul 2009, Aaron Whyte wrote:
>
> Imagine two users of fancyapp.com, with their own logins and data and 
> custom skins and whatnot.  The contents of the main page are uncacheable 
> and are totally different depending on the cookies in the request, which 
> tell the server who is logged in.  This is the way nearly every web app 
> works today, and this is also the way a lot of people share a single 
> computer.
> 
> Without any offline support, they can share one browser, if one logs out 
> of fancyapp, and the other logs in.
> 
> If fancyapp supports offline use with Gears, then one of the users can 
> install an offline client, without affecting the other user, because of 
> requiredCookie.
> 
> But if fancyapp supports offline use with HTML5's app cache, then if one 
> user installs an offline client, fancyapp will keep working for that 
> user, but not for the other user, who will have to go get their own 
> computer, browser, profile, or whatever they need to avoid hitting the 
> other user's app cache.
> 
> The engineers at fancyapp could rewrite their mail page so it's just a 
> little router that looks at cookies and makes subsequent requests to 
> user-specific URLs to really load the app.  But that's an inferior user 
> experience, because it introduces an extra round trip to get the initial 
> page properly rendered.  So they'll probably have to support both.

If the application code (HTML, JS, CSS) is all the same for two users, 
then appcache works for multiple users by just having the data for the 
users separate from the logic.

This is the expected model for most apps. For example, your typical blog 
has just one set of CSS for all users.

For systems where the user affects what HTML, JS, and CSS is served back, 
the spec as written pretty much requires that there be one app per user, 
and one generic "login" app that then redirects to one of those other apps 
-- and where each app has a different base URL, separate manifest, etc.

I think conceptually that's actually not a bad idea anyway, to be honest. 
However, I could see that it might not be the preferred model.

An alternative that we could explore in a future version is to have the 
manifest include a manifest name, and then have script that allows you to 
"activate" a particular manifest name for a given appcache.

So each appcache group would be futher subdivided into named subgroups, 
and for a given manifest URL with such a group of subgroups, one subgroup 
would be the default one at a time. The inactive ones would just lie 
dormant, but and the active ones would act like now, but there'd be a 
scripted way to change the default (and maybe query what available 
variants exist for the current appcache), so that you could log back in as 
someone else by just making the script pick the other user's variant, and 
then reloading.

I've noted this in the spec as a possible v2 feature.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'