Honza Bambas (:mayhemer) Reporter
	Description • 12 years ago

This is needed for jars for app cache (for a new upcoming variant of a patch that doesn't make netwerk use nsISSM).

Since we don't want necko include nsISSM, we cannot actually use nsIScriptSecurityManager::NO_APP_ID to check whether the load context's extended origin is really "extended".  Also, it's not probably the correct way anyway.

For app cache data jars I'm adding extendedOrigin string to the groupID identifying the cache (groupID actually is the URL of the offline app cache manifest).

For back/forward compatibility when looking for a cache or creating a new one, I must omit adding this extended origin string to the groupID, when load comes from a "normal" web content app cache page.

So, I need a convenience and correct way to determine whether extendedOrigin is extended or just a "normal" origin of a URI.


Option:
- expose also "origin" that I can compare to
- expose bool isExtended
- add an arg to GetExtendedOrigin like bool aOnlyIfExtended

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 1 • 12 years ago

extendedOrigin == origin  if and only if  appid==0 && isInBrowserElement==false

	Honza Bambas (:mayhemer) Reporter
	Comment 2 • 12 years ago

Please see bug 756717 comment 7.

	Honza Bambas (:mayhemer) Reporter
	Comment 3 • 12 years ago

(In reply to Jonas Sicking (:sicking) from comment #1)
> extendedOrigin == origin  if and only if  appid==0 &&
> isInBrowserElement==false

You mean appid==nsIScriptSecurityManager::NO_APP_ID, don't you? 

Or would you agree to just compare to 0?  And do you really believe it is the correct way to do this check?

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 4 • 12 years ago

I'm fine with moving that constant definition somewhere else.

However I don't quite understand the why you can't use extendedOrigin. I know we can't use it in localStorage because the localStorage code uses reversed domain names in order to calculate quota on a eTLD+1 basis. Are we needing to do something similar for appcache?

	Jason Duell
	Comment 5 • 12 years ago

> I need a convenience and correct way to determine whether extendedOrigin 
> is extended or just a "normal" origin of a URI.

if (origin == loadContext.GetExtendedOrigin(URI)) ? :)

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 6 • 12 years ago

(In reply to Honza Bambas (:mayhemer) from comment #0)
> For app cache data jars I'm adding extendedOrigin string to the groupID
> identifying the cache (groupID actually is the URL of the offline app cache
> manifest).

Ah! Now I get it, that makes sense.

What I would propose that you do is to look for |appid == 0 && !isInBrowserElement| and if that is true, you append the appid and isInBrowserElement flag to the groupID.

I can't think of a really great solution for where to put the constant definition. It really sucks that we have no place for putting security infrastructure which Necko and the rest of gecko can use, but that's absolutely out-of-scope for this bug.

The best solution I can think of is to put a #define in NetUtil.h (or somewhere else) which defines NECKO_NO_APP_ID and then leave a comment both there and in nsIScriptSecurityManager.h to tell people to update both places if one is updated.

I'd declare the whole 'extendedOrigin' idea a dud at this point. I think only indexedDB is going to end up using it.

	Honza Bambas (:mayhemer) Reporter
	Comment 7 • 12 years ago

(In reply to Jonas Sicking (:sicking) from comment #6)
> (In reply to Honza Bambas (:mayhemer) from comment #0)
> > For app cache data jars I'm adding extendedOrigin string to the groupID
> > identifying the cache (groupID actually is the URL of the offline app cache
> > manifest).
> 
> Ah! Now I get it, that makes sense.
> 
> What I would propose that you do is to look for |appid == 0 &&
> !isInBrowserElement| and if that is true, you append the appid and
> isInBrowserElement flag to the groupID.
> 
> I can't think of a really great solution for where to put the constant
> definition. It really sucks that we have no place for putting security
> infrastructure which Necko and the rest of gecko can use, but that's
> absolutely out-of-scope for this bug.
> 
> The best solution I can think of is to put a #define in NetUtil.h (or
> somewhere else) which defines NECKO_NO_APP_ID and then leave a comment both
> there and in nsIScriptSecurityManager.h to tell people to update both places
> if one is updated.
> 
> I'd declare the whole 'extendedOrigin' idea a dud at this point. I think
> only indexedDB is going to end up using it.

This is what I needed to here.  Thanks Jonas.  Since I presume extendedOrigin is never (or at least for a long) about to be based on something different then appid and ismozbrwouser then:

- I'll stop using extendedOrigin as suffix for groupID
- I'll add constant NECKO_NO_APP_ID=0 (I believe as a temp fix only) to NetUtil.h
- I'll build the groupID suffix my self from appID and mozbrowser flag values directly

This bug is then probably WONTFIX.  I'll close it when the work on app cache jars is done.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 8 • 12 years ago

soundsgood. Thanks!