New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vue Cometd plugin #765

Closed
fergardi opened this Issue Jan 22, 2018 · 9 comments

Comments

Projects
None yet
3 participants
@fergardi

fergardi commented Jan 22, 2018

Hello!

I need a CometD plugin for VueJS and, since you have no one yet, I'll try to build one from scratch based on the Angular one and make a PR to your repository with the result.

See you!

@sbordet

This comment has been minimized.

Member

sbordet commented Jan 22, 2018

Note that CometD offers vanilla bindings (i.e. ones based on pure JavaScript with no other dependencies) and support both AMD and CommonJS/NodeJS styles of modules.

The only reason to have Angular 1.x bindings are that it has its own module system and that it requires to call $apply() to WebSocket callbacks.

From what I understand, Vue does not have any wrapper around XMLHttpRequest or WebSocket and does not require any special treatment of their callbacks, so you should be good with vanilla CometD with whatever module system you like.

See https://docs.cometd.org/current/reference/#_javascript.

Let us know how it goes. Thanks !

@fergardi

This comment has been minimized.

fergardi commented Feb 12, 2018

Hello! I was able to replicate the vanilla code in my custom VueCometD plugin (which I intent to PR you with after some testing, don't worry).

Now the problem I'm experiencing is with sending the additional requestHeaders in order to add my Authorization Bearer token. Following the documentation, it is done with:

let cometd = new library.CometD()
cometd.unregisterTransports()
cometd.configure({
  ...,
  requestHeaders: {
    Authorization: 'Bearer xxxxxxxxxxxx'
  },
  ...
})

But I keep getting 401 from my Jetty server! And in the WS devtools inspector, I cannot see my custom header being sent to the server. I've tried every possible combination with no luck so far.

image

What am I doing wrong?

Thanks in advance.

@sbordet

This comment has been minimized.

Member

sbordet commented Feb 13, 2018

By default Jetty does not implement the Bearer authentication, so you have to plug something inside Jetty server to make this work.

The vanilla CometD transport does handle request headers in the format you have specified, but only for the http transports, not websocket because there are no browser APIs to set a HTTP header when opening a WebSocket connection.

If you disable the websocket transport with:

cometd.websocketEnabled=false;

does it work ?

@fergardi

This comment has been minimized.

fergardi commented Feb 13, 2018

Thanks for your response, but it does not even handshake with that configuration.

@sbordet

This comment has been minimized.

Member

sbordet commented Feb 13, 2018

Why do you have this:

cometd.unregisterTransports()

Make sure that you client and your server have the http transports available.
They are the only way to send the Authorization header.

@fergardi

This comment has been minimized.

fergardi commented Feb 14, 2018

That code comes from the Angular plugin, on which I've based mine.

https://github.com/cometd/cometd/blob/master/cometd-javascript/angular/src/main/webapp/js/angular/angular-cometd.js#L79

I do believe both have the http transport enabled, cause I use OAuth for http/s API Authorization already.

I still believe I'm missing something here. How is usually OAuth Bearer token security handled with WS, due to the missing headers limitation?

@sbordet

This comment has been minimized.

Member

sbordet commented Feb 14, 2018

The Bearer token cannot be handled with WebSocket.

The angular binding replaces the vanilla transports with its own versions of those transports, so it unregisters all transports (the vanilla ones) before registering the angular specific transports under the same names.

If you are using the vanilla transports for Vue, you don't need to unregister the transports.

@sbordet

This comment has been minimized.

Member

sbordet commented Sep 4, 2018

Closing as the Vue plugin seemed ok (hey, we expect the PR!), but the issue went into WebSocket authentication issues that are not CometD related.

@sbordet sbordet closed this Sep 4, 2018

@sbordet sbordet modified the milestone: 3.1.5 Sep 4, 2018

@michaelherger

This comment has been minimized.

michaelherger commented Nov 6, 2018

@fergardi would you have working Vue/CometD code?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment