Hi,
we are developing an application around vtk.js, wslink and paraview web.
Our need implies for an application to send to the server a custom information on connection.
The most straightforward would be to send this information via headers. However from what I saw, it doesn’t seem possible with current vtk.js and wslink-js capabilities.
What would you think about allowing this feature, that is, allowing an application to pass a custom header when connecting with vtk.js?
It seems to me the best way would be to extend WSLinkClient, and allow to add this header name+value among the options dictionary. What do you think?
If it suits you I could even propose the PR.
Unless I’m missing what you are asking for? Why do you need to pass something before being connected?
So far, you can pass anything before starting a new process for a given client. No other client can connect to that process. And once connected + authenticated, you can pass anything to that process.
The aim is to authentify, as the static secret-based authentication is not suitable for our use case.
The client needs to pass a custom data field at the moment of connection, to allow the server to accept or reject connection. After connection is established would be already too late.
But what I’m saying you should not even start a new process if it is the wrong user. Once a process was started for a given user, only that user should have that token.
You mean, validation should be done in a front process, who check the auth, and if all is right, generates a paraview server process. It would imply this server should be launched with a (unique unguessable) token which is transmitted to the client. The client would then connect to the process using this token (using the current ‘secret’ mechanism)?
This wouldn’t really suit for a couple of reasons. We already have an authentication mechanism via tokens, and it would mean doubling it. That would be both kind of clumsy, and bring potential failure points. We need the same existing token to be used at all times.
In addition, in some case the process launch will be dissociated from a client connection, and several clients can connect to the same process (to see the same thing).
BTW, that token is not static. It is when the user fail to provide it as there is no option to disable that authentication.
When you mean user, you mean the launcher process? Indeed but I mean static in a way that for a given server process, the token will be fixed. This can’t work for us; what we need is that the server receives a token, whatever it is, and validates it by an outside mechanism.
Your summary is indeed correct with what I was suggesting.
If you want to validate the connection on your own, you should already be able to do that assuming the WS request has the given header/cookie/url within the Python side.
If not what is your plan on adding header to the websocket request?
If you want to validate the connection on your own, you should already be able to do that assuming the WS request has the given header/cookie/url within the Python side.
Indeed on server side I should already be able to validate the incoming request (didn’t test yet but I saw the onConnect has a request parameter which should contain all the relevant info).
The issue is to be able to add this info to the creation request on client side.
So the point is that a client can connect to a particular instance via websocket (let say ws://ourdomain:8080) if he has the right info, but if he tries to connect to another running instance ws://ourdomain:8081, the connection will be rejected.
Damn, you’re right. Wouldn’t have imagined it’s impossible
I was so convinced I didn’t even think to check beforehand. Should have done it first thing.
Thank you, and sorry to annoy you with this. Will have to find an alternative method.
