Print

Print


(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