 |
 |
Just a quick reply to @***@***.***>. Andy is correct that fallback or fall-through from the ZTN token or whatever we wish to call it can be (re-)implemented in dCache if so desired. As for carrying tokens across redirects, that is largely the client's responsibility, so dCache just uses what it receives. The only moment in which we would have to make sure this is happening inside of dCache is when we all agree upon native xroot TPC using tokens. I have not heard anything specific about whether we are moving forward with that or not, so if I am behind the times, please let me know! Thanks, Al ________________________________________________ Albert L. Rossi Senior Software Developer Scientific Computing Division, Scientific Data Services, Distributed Data Development FCC 229A Mail Station 369 (FCC 2W) Fermi National Accelerator Laboratory Batavia, IL 60510 (630) 840-3023 ________________________________ From: Andrew Hanushevsky ***@***.***> Sent: Saturday, February 19, 2022 1:56 AM To: xrootd/xrootd ***@***.***> Cc: Albert Rossi ***@***.***>; Mention ***@***.***> Subject: Re: [xrootd/xrootd] ZTN and Scitokens auth (Issue #1584) The way you would do it is to place the token on the url in the standard way: xroot;//host//my/path?authz=[brearer%20] Yes, this is very inconvenient but no worse than what you have to do for AWS. The nit here is "bearer%20" you may need to add that if the token you got doesn't have it. I've seen tokens both ways and I wish we could standardize that because it will confuse people to no end. Generally, the idea was that a url provider would give you a fully formed url so you don't think twice about it. Of course, for the one-off copies or whatever there is no url provider and, in fact, I have no idea how a person would get a token for a one-off copy (probably harder than we think ; enough to and make a user want x509 back). Now, to other stuff. Whatever cgi a user specified should be carried across redirection. If that is not being done then it is a bug. I think we corrected that problem for certain edge cases some time ago. I don't know if that is also true for dCache but it should be as it's part of the protocol specification. As for @alrossi<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_alrossi&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=ucA4Tp8POP88xObT6UOerb4nKUJKEg0CcfTBGnhAa3V1vyyoHuKAgI6wx4LJ1-Zt&s=BLT43EYvVoc9bByrRpUl50LmO_QQdOo5BpHDeVWn-xo&e=> getting confused, he should be confused because the "backup token" idea came out of the blue. So, Al you are right, the original plan was exactly what you thought it was. That said, I don't mind extending things. I just want to make sure it doesn't create new problems. I think @alrossi<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_alrossi&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=ucA4Tp8POP88xObT6UOerb4nKUJKEg0CcfTBGnhAa3V1vyyoHuKAgI6wx4LJ1-Zt&s=BLT43EYvVoc9bByrRpUl50LmO_QQdOo5BpHDeVWn-xo&e=> is on board with that and can make the appropriate changes. I can place the token in the creds field as it's a no-brainer. Then you can use it as you see fit in the SciTokens plug-in. Anyway, let me know whether or not you want access to the ztn token. Please @bbockelm<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_bbockelm&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=ucA4Tp8POP88xObT6UOerb4nKUJKEg0CcfTBGnhAa3V1vyyoHuKAgI6wx4LJ1-Zt&s=pD-KT2Pmmm_w-WOpdB8xhwqyCxgu4_CCiFc5U2ZBiiE&e=> finish off the review comments in the voms mapfile pull request. We are almost there. — Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_xrootd_xrootd_issues_1584-23issuecomment-2D1045961770&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=ucA4Tp8POP88xObT6UOerb4nKUJKEg0CcfTBGnhAa3V1vyyoHuKAgI6wx4LJ1-Zt&s=KAgj2z-aM7tXp3ymoOoHCmr4UXEtWg1M98s57dn8LOU&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AA6NBHBY2CQLSMZPGPKDZ4DU35EMJANCNFSM5LUMRMZQ&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=ucA4Tp8POP88xObT6UOerb4nKUJKEg0CcfTBGnhAa3V1vyyoHuKAgI6wx4LJ1-Zt&s=iUQo-ncH9A7ggZs81ZxpzUuBHlUVBqG9K3JScDctPZA&e=>. Triage notifications on the go with GitHub Mobile for iOS<https://urldefense.proofpoint.com/v2/url?u=https-3A__apps.apple.com_app_apple-2Dstore_id1477376905-3Fct-3Dnotification-2Demail-26mt-3D8-26pt-3D524675&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=ucA4Tp8POP88xObT6UOerb4nKUJKEg0CcfTBGnhAa3V1vyyoHuKAgI6wx4LJ1-Zt&s=VOYV1YEJncp6tY1vB29MPWvA5AXEqEa7gwhzsSE0QQY&e=> or Android<https://urldefense.proofpoint.com/v2/url?u=https-3A__play.google.com_store_apps_details-3Fid-3Dcom.github.android-26referrer-3Dutm-5Fcampaign-253Dnotification-2Demail-2526utm-5Fmedium-253Demail-2526utm-5Fsource-253Dgithub&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=ucA4Tp8POP88xObT6UOerb4nKUJKEg0CcfTBGnhAa3V1vyyoHuKAgI6wx4LJ1-Zt&s=7zvb7gyZe6Eyt1zYmrE2Ug_ckuGNLV0Kjx5pLajKhIs&e=>. You are receiving this because you were mentioned.Message ID: ***@***.***> -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1584#issuecomment-1046028142 You are receiving this because you commented. Message ID: <[log in to unmask]> ######################################################################## 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