(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: 1. Extend the file-open packet type to also include the security entity information, much like the LFN record is done today. 2. 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 or view it on GitHub: https://github.com/xrootd/xrootd/issues/1987 You are receiving this because you are subscribed to this thread. 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