Well, this is an issue for sure. The only solution I see is that the HTTP
engine would have to cache the token for a subsequent reconnection and
somehow convince the client to not resend the token in the clear. However,
many people say that TLS is a trivial overhead. If it is, then this kind
of shenanigans (and they are not trivial to pull of correctly) is hardly
worth considering.
On Tue, 14 Jul 2020, riccardodimaria wrote:
> Predicament 2: Many thanks for the explanation. However, in view of Tokens replacing x509, I am not sure how to solve this from the user PoV. Trying to explain, the user will always have only his token while contacting either the central redirector or the cache itself. AFAIU, the best way to set the cluster for a "fast redirection, distributed authentication, fast unencrypted data access" is to have the setup I am using ATM.
> Am I missing something in the picture?
>
> --
> You are receiving this because you commented.
> Reply to this email directly or view it on GitHub:
> https://github.com/xrootd/xrootd/issues/1251#issuecomment-658054658
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/xrootd/xrootd/issues/1251#issuecomment-658542929",
"url": "https://github.com/xrootd/xrootd/issues/1251#issuecomment-658542929",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://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