Ari Heitner wrote:
>
> On Tue, 2 Jan 2001, John Bandhauer wrote:
>
> > Ari Heitner wrote:
> >
> > > and my problem is still the same: i need XPCOM to see typelib's even if they're
> > > not in components/, since i don't have access to that directory. I'd be happy
> >
> > xpcom is built of multiple subsystems. You are pointing out a
> > method of the component manager. The part of interest here is the
> > Type Info Loader (xpti). The current mozilla-the-browser really
> > only needed to load xpt files from one place. So that is what the
> > current code does. It was not completely clear to me whether or
> > not you are doing your own embedding of xpcom (where you can
> > build your own version of the binaries) or you are instead
> > building a system that relies on users having binaries from other
> > vendors. If you have control of the binaries and having xpt files
> > come from only one directory (but not the current place) is OK
> > with you then you can reimplement:
> >
> > xptiInterfaceInfoManager::GetComponentsDir
> > and
> > xptiInterfaceInfoManager::GetManifestDir
> > at
> >
>http://lxr.mozilla.org/seamonkey/source/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp#162
> >
> > GetComponentsDir is the place where xpti will find and load xpt
> > files.
> > GetManifestDir is the place where xpti will read and write
> > xpti.dat.
> >
> > Both of these methods need to build and return a new object
> > implementing nsILocalFile each time they are called.
> >
> > If you reimplement these methods to point elsewhere and copy all
> > the existing xpt files to that new place then it should just
> > work.
> >
> > An alternative to the above is to leave that code alone and
> > instead change your copy of the implementation of
> > "GetDirectoryFromDirService(NS_XPCOM_COMPONENT_DIR, aDir);". I
> > *think* that would change where xpti finds xpt files *and* where
> > the native component loader find .dll files too. I'm not sure if
> > you want that or not.
> >
> > If you really need to have the xpti system find xpt files in
> > various places then there is a much larger problem. This would
> > require larger structural changes to xpti. This would require the
> > concept of a search path, a more complicated file search scheme,
> > and another level in the internal hierarchy to describe the
> > directory in which a given xpt file was found. I'm in no rush to
> > do that if it is not *really* needed.
> >
> I'm not sure that's really what I need.
>
> On further reflection, late registration of XPCOM components is key to Sash
> (from the Sash webliction's point of view). That is, once you're running
> untrusted JS (which is what Sash is all about; it's just that JS now has some
> useful system libraries. if you're not careful, evil can easily ensue :), only
> the components specifically permitted to this weblication should be
> available. Currently, this is acheived by inserting XPCOM objects (representing
> libraries authorized to the weblication) into the ComponentManager at
> runtime. This seems to suggest that all we really need is runtime insertion of
> typelibs, the same way we can register new XPCOM objects.
This does not follow at all. Don't confuse type information with
specific component implementations. I assume that you are talking
only about access via xpconnect from JavaScript to xpcom
components written in C++. In that case the proper mechanism for
security is to write an implemention of nsIXPCSecurityManager and
install it using either
nsIXPConnect::setSecurityManagerForJSContext or
nsIXPConnect::setDefaultSecurityManager.
What you say below does not make it clear that you really need to
dynamically add type info to the set of known type information,
only that you want to dynamically control access to the
components. That is what nsIXPCSecurityManager is for. If your
system does in fact have a finite set of xpt files known at
startup time, then I don't see any reason to fiddle with xpti
(other than to change where xpti finds those files in your
system).
Again, keep in mind that the component registry is not where xpti
info is stored. xpti.dat is used as a cached 'index' to let xpti
track where to find and load type info incrementally on demand.
You *can* dynamically add new type info by writing new xpt files
to the directory where those files are stored and forcing an
autoregistration. This is not an activity for which xpti is
particularly optimized.
John.
>
> Now really we could use the full ideal system supporting multiple
> registries. Sash would just have its own registry, containing all installed
> extension libraries. We'd only make the appropriate ones available through
> XPConnect during weblication startup. If this is what's preferred, I'd be
> willing to make xpti do the necessary magic. Blizzard pointed out the bug
> (http://bugzilla.mozilla.org/show_bug.cgi?id=14923) about this....wow, that's
> old :)
>
> But I'm not 100% convinced that's what I need. If I could just say to the
> ComponentManger "here's another typelib for you" at runtime (or even have it
> look for typelibs at the same time/place i register component shared
> libraries) that would be fine. This would save the pain of coming up with
> policies on multiple typelibs. Of course it presupposes that loading a typelib
> dynamically is easy ...
>
> Well. Either way, this *is* how i want to do things, since it makes Sash
> *extremely* clean (Sash becomes just a formalization for "writing applications
> in JS, using nice libraries exposed through XPConnect" which would make
> the Free version even cleaner than the 'doze version which would make me
> mega happy). So I'm putting myself at ... well... whoever's disposal.
>
> cheers,
>
> ari
