 |
 |
@simonmichal , you asked: > Would it be a big hassle to support this on dCache side? I've been thinking about this and the short answer is "yes, it would be a big hassle", but perhaps an explanation might lead to future improvements. The original idea for xroot support in dCache was that the door handles all namespace (non-data) operations, while the pool handles requests directly involving the file's data. So, when a client does `kXR_open` on a file (in the door), dCache would ensure the file is available from a pool (for reading) or that there is a pool ready to accept the data (for writing). In either case, the pool promises to accept the client and the door returns that promise in the form of a single-use bearer token, which the client then presents to the pool when making the `kXR_open` request (it's part of the opaque). If the client makes any other requests to the pool (including a subsequent `kXR_open` request) then it is redirected back to the door. This bearer token is important because, by presenting it, the pool knows the client has authenticated (to the door) and is authorised to read the file. Without this token, the pool (currently) doesn't know if the client is allowed to read the file or upload data. A side-effect is that the client doesn't need to undertake strong authentication when connecting to the pool (for example, no GSI authn). Later, we allowed some non-data related client requests on the pool (`kXR_stat`, `kXR_query/QCksum`). These are allowed _after_ the client as issued `kXR_open` with the bearer token in the opaque, since this authenticates and authorises the client. However, these requests are only allowed against the opened file, if the client were to issue `kXR_query/QCksum` against another file then the pool will redirect the client back to the door. The problem comes when a client connects and issues a request (e.g., `kXR_query) without first making a `kXR_open` request with an opaque token. In this case (I believe) we currently don't have any good way to connect this new client connection with any previous client activity. This is a problem, as the client didn't authenticate strongly (so the pool doesn't know the client's identity) and the pool doesn't know from which door the client came (so the pool cannot redirect the client back to the door). So, the pool can try to figure out to which door it could redirect the client. This is tricky, since different doors could have different behaviours (allowed authentication, root directory, namespace mapping, etc). I'm not sure if this could be solved for the most general case. As a possible long-term consideration: would it make sense to allow a redirection response to include some kind of token that the client should present on login? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1359#issuecomment-742461854 ######################################################################## 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