Web socket connection

Development
1

I'm trying to connect an iOS app developed in Swift to the socket implementation in OctoPrint. This is new to me. So, I'm struggling a bit with how to get connected.

First, I'm using this library: https://github.com/tidwall/SwiftWebSocket

I'm trying to simply figure out where to connect to the server - the address. (Baby steps here.) I've tried the following:

wss://octopi.local:8081 -> I thought this was the default location
wss://octopi.local:5000

And, then I found a specific directory that it might be located within and I tried that:

wss://octopi.local:8081/socksjs/websocket
wss://octopi.local:5000/socksjs/websocket

I'm expecting that the next thing that I will need to do is pass an API key, but I'm just wanting to get an authentication error at this point! :grinning:

Please let me know if my approach is even correct and what the correct address would be. Again, this is the first time I've really dealt with web sockets. Thanks!

2

I haven't exercised many of the OctoPrint interfaces, only the REST one.

I know that there's a JavaScript client API which includes a socket interface. Although the document doesn't indicate endpoints and such, the code itself might. Reading through that, I'm not seeing anything that looks like defining arguments or anything.

Perhaps @foosel can assist.

1 Like
3

Might be too late for this reply. You may find an example in the source code of OctoPod. It is open source and uses Starscream to connect to what Tornado calls "raw websockets". This class is what connects to the raw websocket.

An example of URL to connect to is: http://octopi.local/sockjs/websocket

2 Likes
4

Sorry to revive an old thread, but we in the Replicape community were working on Toggle as a touch screen UI for Replicape-based printers using the Manga Screen 2.

We had to do a major overhaul of the websocket interface for 1.3.10 with the force login plugin, but 1.3.11 broke the websocket again... I'm trying to figure out where the documentation is for the proper way of interacting with the websocket in a way that's not going to break at every OctoPrint update.

@foosel is there a standard way to get the information stream ? (we parse the temps, ETA, printer status from the socket feed) I'm not even able to read the socket with my browser's simple websocket client tester on ws://octoprint.local/sockjs/websocket anymore. What's changed, and will it ever be stable or should we just stick to using REST?

5

Your octoprint.log might have some pertinent information (which she might ask for).

6

Docs are here: http://docs.octoprint.org/en/master/api/push.html

Take note that starting with 1.3.10 you need to authenticate on the socket to get messages pushed.

7

@foosel yes, we did implement that, but for some reason the connection doesn't establish properly after upgrading from 1.3.10 to 1.3.11.

I'll look at the docs to see if we did it wrong the first time around and fix it.

Thanks for the link!

8

Hey @Jon_C, I just saw your question on the Q&A form. I think it might make more sense to tackle this here then via a broadcast, especially since I have some questions :wink:

/sockjs/websocket is definitely the right one and it works, otherwise the UI wouldn't work at all. The question is, what issues are you running into exactly? I'm currently investigating

Is it something similar?

9

Hi @foosel yes we can keep the discussion here. I just thought I was doing something wrong...

So on my side what I'm doing is using the Firefox extension Simple websocket client to try and connect to the websocket from my LAN...

And I get an error - but I don't think it's a 403, will confirm when I get home. My memory tells me it was 404... Hence the worry about having the wrong endpoint :confused:

10

Ok, so, further investigation and a few trial and errors later...

I found the issue we were having with Toggle.

In 1.3.10 the first message was passing out the general API key as part of the first message. The way we were parsing the connection initialization was built around that.

In 1.3.11 this is no longer the case, and the initial message has changed. I simplified the parser to only look for the "connected" keyword and added the user's auth key as part of the client config, and now it works again...

But the Simple websocket client won't connect... I get the dialog "undefined error" whenever I try. Makes it really confusing to me. Tried with ws:// and wss:// - no luck!

11

I can reproduce this with the mentioned extension. Reason for the unhelpful undefined message is a 403 returned from the websocket, which sounds like issue 3193. I'm investigating. What is making this tricky is that I can only reproduce it against one instance here, and not against my development machine, not even through a reconfigured OctoPi haproxy.

12

So the problem is the following... The extension is setting an Origin header (moz-extension://a65f6eaa-25cb-4ba3-b88e-6e983a0bec72), and since 1.3.11 introduced proper CORS checking also on the websocket, a 403 is triggered. Configure the instance to allow cross site access and the extension works.

This should only be an issue with browser based socket clients since with stand alone clients you would normally not set an Origin header to begin with.

For reference, see

and

1 Like
13

Awesome, thanks for figuring that out! I'll see that we document that properly for developers who want to work with this as part of our Toggle client :slight_smile:

And I'm glad it's only a single issue and not multiple ones :wink: makes debugging easier.

Cheers,
Jon