 |
 |
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]<token> 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 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 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 finish off the review comments in the voms mapfile pull request. We are almost there. -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1584#issuecomment-1045961770 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