> > Tom Scavo wrote: > > On Mon, Sep 15, 2008 at 6:56 PM, Martin Feller > <[EMAIL PROTECTED]> wrote: > >> Oh, hang on, you mean that we better put the right protocol > >> (http/s) in the epr of a job, depending on how MEJS is configured? > > > > Yes, but more generally, conflicting security descriptors should not > > be allowed. In particular, I'm focused on this: > > > >> Say MJFS allows only GSITransport and MEJS only GSISecureMessage. > >> You submit a job in batch mode using MJFS, and get an epr > back (with https://* in the address) > >> Then you want to destroy the job using that epr, but MEJS > only supports GSISecureMessage > > => boom. > > > > This can be avoided, right? (That's a real question, since > I haven't > > programmatically accessed a security descriptor myself.) > > > > Tom > > yes, in 4.0 one can programmatically access the security > descriptor of a service. > it seems that it changed slightly in 4.2, so i'd have to > confirm with rachana, but i can't > imagine that it's impossible in 4.2.
Yes, it is feasible in GT 4.2 to access it. The descriptor is stored as part of the ServiceSecuirtyDescriptor class. Rachana > And yes, it should not be too much of an effort then to > either throw an exception in > case of an inappropriate MEJS service security descriptor, or > to put the right protocol > in the epr returned back to the client. > i'll open a bug for that. > > Martin >
