@bbockelm Concerning your question:

@esindril - can you kindly remind me of the use case here? I recall talking about it but don't think > I wrote it down. That is, if you have libXrdAccEOS, why doesn't the following work:

ofs.authlib libXrdMacaroons.so libXrdAccEOS.so
?

I think you already provided the answer in you subsequent comment:

The second unpleasant piece in this code is the fact that, within the HTTP handler, we need to
have access to the XrdAccAuthorize object used by the OFS to generate the appropriate
permissions for the Macaroon.

Is there such a way to do that? This is currently accomplished by directly constructing the object > and via a reimplementation of the ofs.authlib logic. There's not much gain if we significantly clean > up this usage only to add more complexity elsewhere. What you point out only helps the case of > making an authorization object for the ofs and not recreating it in the plugin.

I actually have a similar patch for the XrdSciTokens library, but I'll for the the things to settle on a cleaner solution for all this chaining business.

@abh3

If so, I can plop a pointer to an authorization object in the XrdOucEnv
object passed to the protocol plugin. Then you'll have access to all the
methods using whatever the config was in the ofs. Will that be better for you?

I think this looks reasonable and it's already cascaded from the XrdHttpProtocol to any XrdHttpExtHandler object. Anyhow, this will only be available in R5, right?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1