Hello,

when running xrdcp against our multiprotocol xroot door (i.e., that supports ZTN and GSI, in that order), the client will warn that ZTN is not supported if the door/server does not also enforce TLS. For example, 1095 has TLS optional:

[arossi@fndcatemp1 ~]$ httokendecode 
/run/user/8773/bt_u8773 not found
[arossi@fndcatemp1 ~]$ voms-proxy-init
Your identity: /DC=org/DC=cilogon/C=US/O=Fermi National Accelerator Laboratory/OU=People/CN=Al Rossi/CN=UID:arossi
Creating proxy ................................. Done

Your proxy is valid until Wed Feb 22 20:05:51 2023
[arossi@fndcatemp1 ~]$ xrdcp5x data/data_1b xroot://fndcatemp2.fnal.gov:1095///pnfs/fs/usr/fermilab/users/arossi/any/data-`suffix`
security protocol 'ztn' disallowed for non-TLS connections.
[1B/1B][100%][==================================================][1B/s]  
[arossi@fndcatemp1 ~]$

Now, since the client was not given a token, but just a GSI credential, it seems superfluous to warn about TLS, given the client will not try ZTN anyway.

Would it be possible to reverse the internal checks in the client, such that it looks for the bearer token first? That way, if it does not find the token, it just skips the protocol and moves on to GSI?

Of course, the ordering of the protocols by the server would also take care of this case (i.e., telling the client to try GSI first). But it does seem to me that the client itself ought to check for the presence of a token first.

This is not urgent, just a suggestion.

Thanks, Al

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <xrootd/xrootd/issues/1927@github.com>

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