Allow consumers of nsILoadContext recognize whether extendedOrigin really is extended w/o use of nsIScriptSecurityManager

RESOLVED WONTFIX

Status

()

Core
DOM
RESOLVED WONTFIX
6 years ago
6 years ago

People

(Reporter: mayhemer, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 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
(Reporter)

Updated

6 years ago
Blocks: 756717
extendedOrigin == origin  if and only if  appid==0 && isInBrowserElement==false
(Reporter)

Comment 2

6 years ago
Please see bug 756717 comment 7.
(Reporter)

Comment 3

6 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?
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?
> 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)) ? :)
(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.
(Reporter)

Comment 7

6 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.
soundsgood. Thanks!
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.