 |
 |
@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 or view it on GitHub: https://github.com/xrootd/xrootd/pull/1147#issuecomment-595162336 ######################################################################## 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