We have a use case where we would love to distribute data from CERN EOS via HTTP, with authorization controlled with macaroons (so we wouldn’t have to worry about user account mapping and credential distribution on the clients). At the moment it appears that we need to provide an Authorization: Bearer xxx header in the HTTP request since it doesn’t seem like we can embed the macaroon as a query string in the case of EOS. Is there a way to provide this information to TFile::Open on a file-by-file basis? Using the BEARER_TOKEN environment variable would presumably work as a one-off but this really has a different use case (and isn’t really appropriate if we have a bunch of different macaroons).
for the time being, ROOT does not have dedicated code to talk directly to macaroons.
Davix (to be phased out eventually) indeed supports BEARER_TOKEN, BEARER_TOKEN_FILE and can search also in ${XDG_RUNTIME_DIR}/bt_u<userID> or /tmp/bt_u<userID>.
The curl-based http backend is pretty new. Here I could imagine that we can adapt it relatively easily to extend the http header.
On the xroot side, I don’t yet know how talking to macaroons works, but I can try asking around. It will take a bit of time, because the xroot maintainers are travelling now.
Let us know what you consider the best course of action.
Thanks for the response! In the short term, I’ve found that both dCache and EOS will support embedding the macaroon in the URL, so the urgency is somewhat reduced. However it would still be very useful to have a header-setting functionality for HTTP access since we might need to interact with other stores with similar behavior. For sure curl supports setting arbitrary headers so some interface to this capability in the curl backend would be extremely useful.
I think I agree, so let me invite @jblomer to have a look if that’s something to be added for the curl backend.
Just out of interest, if you have the time, could you post a link / example on how to embed the macaroon in the URL, so it’s findable from this post?
As far as the scitoken flavor of macaroons are concerned, there is a standard procedure on how to discover them by evaluating environment settings: https://cds.cern.ch/record/2813819/files/document.pdf (Section 3).
It’s on the plan to add bearer tokens to TCurlFile, and at this point TCurlFile could get an interface to set the bearer token. This may be preferable over another TFile::Open() option that eventually would only be relevant for HTTP URLs.
Thanks for the info. I completely agree that it would make more sense to have an interface to a TCurlFile to set the token rather than adding another TFile::Open option - if we’re doing this at all we know we are dealing with an HTTP file to start with…
@StephanH the exact method to embed depends on the service: for dCache one can use https://…/file?authz=<macaroon>, while for EOS the intention is to allow https://…/file?authz=Bearer%20<macaroon> although there is currently a small bug in EOS preventing that from working (should be fixed shortly). The latter is unfortunately not well documented.