We have reviewed this and, frankly, we don't see any way of doing a native implementation that would satisfy all concerned parties short of implementing a rather complex set of rules, even then it would be problematic. So, the best we would be able to do is provide a post-authentication connection management plugin. The unfortunate part is that wouldn't work with SciTokens because SciTokens totally subverts the authentication path rendering any plug-in that relies on authentication useless. So, if you plan on using SciTokens (and I think you may have to whether you want to or not) anything we do along these lines will not work. So, please understand the conundrum. While we would like to address this, the landscape is changing faster than any solution we can devise. Every time we make forward progress a new external requirement negates it. Sad to say, the only short-term option is to identify the offending user and tell them to stop. Not a scalable solution but from what I understand it's not like everyone is doing this (yet). I wish I could be more positive.


You are receiving this because you are subscribed to this thread.
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/1446#issuecomment-858431157", "url": "https://github.com/xrootd/xrootd/issues/1446#issuecomment-858431157", "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