(This is probably true for the other monitoring packet types but I happened to stumble across this with the f-stream parsing in #1985)

When a file-open record is sent in the f-stream, the record references the login session.

However, for token-based access, the access control is done at the file-level, not at the session level. Typically the session is for some anonymous user (HTTP) or, when using ZTN, potentially a different token.

I can see two obvious options:

Extend the file-open packet type to also include the security entity information, much like the LFN record is done today.
Some complex setup where we introduce a new f-stream sub-record type that includes the security entity information and indicated that all following file-open sub-records in the same packet share the same type.

Honestly? I'd prefer simplicity won the day and go with (1). That'd have the side-effect of making the f-stream easier to use as one wouldn't even need to capture user login packets anymore - they'd be embedded in the f-stream.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/xrootd/xrootd/issues/1987", "url": "https://github.com/xrootd/xrootd/issues/1987", "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