nordprojects / sirius Goto Github PK

It would be great to be able to write browser-based web apps that communicate with the API. Currently, this isn't possible because sirius doesn't support CORS (Cross-Origin Resource Sharing).

The browser's same-origin policy means a web app running at http://my-great-app.com is restricted in what kinds of content is can send to another domain, such as http://littleprinter.nordprojects.co.

POST HTTP requests with a Content-Type of text/plain are allowed by browsers, so printing plaintext works. However, application/json, text/html and image/* are blocked which limits the kinds of web apps that can be created.

The solution is for sirius to respond with the correct CORS HTTP headers to tell the browser that it is allowed to make these other types of requests.

You can see a tiny demo web app that tries to send HTML via JSON to the printkey API, but fails due to CORS headers not being present in the API.

References: genmon#26 (comment), genmon#26 (comment), genmon#26 (comment)

For example:

I flashed my bridge a couple months ago and it worked fine until recently. Now the red light is on and stays on. I unplugged the bridge and little printer multiple times, but it still doesn’t work. Has anyone had this problem and have a solution?

The timing seems to be "in the last couple of weeks" which would roughly align with #7 going live. So, I suspect something went wrong there.

Checking server logs, I'm seeing entries coming back from bridges like:

Oct 07 02:11:47.850pm debug app web.1 sirius.protocol.protocol_loop:Received BridgeLog(bridge_address='[redacted]', records=[{'name': 'bridge', 'created': 1570482710.281479, 'process': 465, 'levelno': 50, 'processName': 'MainProcess', 'message': "Unexpected command thread error: - <class 'struct.error'> : unpack requires a string argument of length 16", 'levelname': 'CRITICAL'}, {'name': 'bridge', 'created': 1570482710.303787, 'process': 465, 'levelno': 50, 'processName': 'MainProcess', 'message': ' in file PKGTMP.35950/usr/local/bergcloud-bridge/weminuche_bridge.py, line 391, function executeBridgeCommand - None', 'levelname': 'CRITICAL'}, {'name': 'bridge', 'created': 1570482710.306734, 'process': 465, 'levelno': 50, 'processName': 'MainProcess', 'message': ' in file PKGTMP.35950/usr/local/bergcloud-bridge/weminuche_bridge.py, line 336, function executeCommand - None', 'levelname': 'CRITICAL'}]).

My guess here is something about Python 3's bytes vs str and somehow a byte value like 0x01 is being sent as simply "1" instead of "000...01", or something to that effect. So, depending the image you're trying to print, some aren't impacted? Which might explain why it's working fine for some folks?

If we can gather some specific bridge IDs of those impacted, we can try to verify the issue for individuals, and roll out a fix.

Cannot login to https://littleprinter.nordprojects.co/ by clicking "Sign in with Twitter" Receiving OAuth error from twitter! message:

Hi,

First, thanks for all you guys did at Nord projects to revive this beloved little printer. I recently acquired one, and though it seems that a lot of the functions of the by gone Berg era are no longer there, it is still a very useful IoT device to me.

I am encountering a bug when sharing text from an external app with Little Printers.app that results in the printing of the text 3 times: one time with a nice serif font and the two other times, with a sans serif font.

Would there be something that can be done to modify this behavior? Also is there a way to choose which font it is going to be printed out in?

Hello,

It seems the web interface at https://littleprinter.nordprojects.co/ gives the option to print without face when sending a test message. It presently does not work but I was wondering if it could be an option or if there is a way to activate/deactivate the face print for each printing. My application would be that sometimes I have many successive prints to do, and don't need the face to be filled on my little printer each time.

Thank you

I tried tracking down if I can change this setting myself, but it looks like it's all backend stuff - it would be great if I could set the timezone of my printer to my local timezone, rather than having it be GMT. That way, the date and time header at the top of my print outs would make a little more sense.

I might get around to creating my own pull request on this, but I thought I'd throw this out there first in case anyone else wanted to tackle it first.

(Thanks for helping me revive my Little Printer, by the way!)

Hiya 👋

I've started noodling around on implementing the bridge/print protocol to work on generic printers (early progress video, it works!: http://hi.notjo.sh/1d8a21665ce4). Let's remove some barriers to bring some life back to the LP community! It's got some work before it's a full replacement, but all of the pieces of the puzzle are there. But, I digress...

The only permutation of the host for the websocket that connects successfully is: ws://165.227.233.168/api/v1/connection

Being a responsible Web Citizen, I thought I'd try wss://, and also add the hostname, because, because Security Is Key, and IPs can change! But no matter how I try, it just won't work unless I use exactly the above URI.

Some examples below, using websocat via CLI, for simplicity/reproducibility's sake:

Attempt 1: wss://165.227.233.168/api/v1/connection

Outcome: Rejected with invalid SSL certificate, should be device.li. Good in theory!

$ websocat -v wss://165.227.233.168/api/v1/connection
[INFO  websocat::lints] Auto-inserting the line mode
[INFO  websocat::sessionserve] Serving Line2Message(Stdio) to Message2Line(WsClient("wss://165.227.233.168/api/v1/connection")) with Options { websocket_text_mode: true, websocket_protocol: None, websocket_reply_protocol: None, udp_oneshot_mode: false, unidirectional: false, unidirectional_reverse: false, exit_on_eof: false, oneshot: false, unlink_unix_socket: false, exec_args: [], ws_c_uri: "ws://0.0.0.0/", linemode_strip_newlines: false, linemode_strict: false, origin: None, custom_headers: [], custom_reply_headers: [], websocket_version: None, websocket_dont_close: false, one_message: false, no_auto_linemode: false, buffer_size: 65536, broadcast_queue_len: 16, read_debt_handling: Warn, linemode_zero_terminated: false, restrict_uri: None, serve_static_files: [], exec_set_env: false, reuser_send_zero_msg_on_disconnect: false, process_zero_sighup: false, process_exit_sighup: false, socks_destination: None, auto_socks5: None, socks5_bind_script: None, tls_domain: None, tls_insecure: false, headers_to_env: [], max_parallel_conns: None, ws_ping_interval: None, ws_ping_timeout: None }
[INFO  websocat::stdio_peer] get_stdio_peer (async)
[INFO  websocat::stdio_peer] Setting stdin to nonblocking mode
[INFO  websocat::stdio_peer] Installing signal handler
[INFO  websocat::ws_client_peer] get_ws_client_peer
[INFO  websocat::stdio_peer] Restoring blocking status for stdin
websocat: WebSocketError: TLS failure
[INFO  websocat::stdio_peer] Restoring blocking status for stdin
websocat: error running

Attempt 2: wss://165.227.233.168/api/v1/connection, ignore SSL

Outcome: Says it's connected, but shuts down immediately. When running with another client, I can see it closes with error code 1000. According to the RFC, this counts as a graceful closure)

$ websocat -v --insecure wss://165.227.233.168:443/api/v1/connection
[INFO  websocat::lints] Auto-inserting the line mode
[INFO  websocat::sessionserve] Serving Line2Message(Stdio) to Message2Line(WsClient("wss://165.227.233.168/api/v1/connection")) with Options { websocket_text_mode: true, websocket_protocol: None, websocket_reply_protocol: None, udp_oneshot_mode: false, unidirectional: false, unidirectional_reverse: false, exit_on_eof: false, oneshot: false, unlink_unix_socket: false, exec_args: [], ws_c_uri: "ws://0.0.0.0/", linemode_strip_newlines: false, linemode_strict: false, origin: None, custom_headers: [], custom_reply_headers: [], websocket_version: None, websocket_dont_close: false, one_message: false, no_auto_linemode: false, buffer_size: 65536, broadcast_queue_len: 16, read_debt_handling: Warn, linemode_zero_terminated: false, restrict_uri: None, serve_static_files: [], exec_set_env: false, reuser_send_zero_msg_on_disconnect: false, process_zero_sighup: false, process_exit_sighup: false, socks_destination: None, auto_socks5: None, socks5_bind_script: None, tls_domain: None, tls_insecure: true, headers_to_env: [], max_parallel_conns: None, ws_ping_interval: None, ws_ping_timeout: None }
[INFO  websocat::stdio_peer] get_stdio_peer (async)
[INFO  websocat::stdio_peer] Setting stdin to nonblocking mode
[INFO  websocat::stdio_peer] Installing signal handler
[INFO  websocat::ws_client_peer] get_ws_client_peer
[INFO  websocat::ws_client_peer] Connected to ws
[INFO  websocat::sessionserve] Reverse finished
[INFO  websocat::sessionserve] Reverse shutdown finished
^C[INFO  websocat::stdio_peer] Restoring blocking status for stdin

Attempt 3: wss://device.li/api/v1/connection

Outcome: Same as above, seems like an issue with SSL in general 😢

$ websocat -v wss://device.li:443/api/v1/connection
[INFO  websocat::lints] Auto-inserting the line mode
[INFO  websocat::sessionserve] Serving Line2Message(Stdio) to Message2Line(WsClient("wss://device.li/api/v1/connection")) with Options { websocket_text_mode: true, websocket_protocol: None, websocket_reply_protocol: None, udp_oneshot_mode: false, unidirectional: false, unidirectional_reverse: false, exit_on_eof: false, oneshot: false, unlink_unix_socket: false, exec_args: [], ws_c_uri: "ws://0.0.0.0/", linemode_strip_newlines: false, linemode_strict: false, origin: None, custom_headers: [], custom_reply_headers: [], websocket_version: None, websocket_dont_close: false, one_message: false, no_auto_linemode: false, buffer_size: 65536, broadcast_queue_len: 16, read_debt_handling: Warn, linemode_zero_terminated: false, restrict_uri: None, serve_static_files: [], exec_set_env: false, reuser_send_zero_msg_on_disconnect: false, process_zero_sighup: false, process_exit_sighup: false, socks_destination: None, auto_socks5: None, socks5_bind_script: None, tls_domain: None, tls_insecure: false, headers_to_env: [], max_parallel_conns: None, ws_ping_interval: None, ws_ping_timeout: None }
[INFO  websocat::stdio_peer] get_stdio_peer (async)
[INFO  websocat::stdio_peer] Setting stdin to nonblocking mode
[INFO  websocat::stdio_peer] Installing signal handler
[INFO  websocat::ws_client_peer] get_ws_client_peer
[INFO  websocat::ws_client_peer] Connected to ws
[INFO  websocat::sessionserve] Reverse finished
[INFO  websocat::sessionserve] Reverse shutdown finished
^C[INFO  websocat::stdio_peer] Restoring blocking status for stdin

Attempt 4: ws://device.li/api/v1/connection

Outcome: Connection closes immediately (when run in another client, I see a 301 Moved Permanently, pointing to https://device.ly/api/v1/connection..which kind of makes sense, but still not super helpful here.

$ websocat -v ws://device.li/api/v1/connection
[INFO  websocat::lints] Auto-inserting the line mode
[INFO  websocat::sessionserve] Serving Line2Message(Stdio) to Message2Line(WsClient("ws://device.li/api/v1/connection")) with Options { websocket_text_mode: true, websocket_protocol: None, websocket_reply_protocol: None, udp_oneshot_mode: false, unidirectional: false, unidirectional_reverse: false, exit_on_eof: false, oneshot: false, unlink_unix_socket: false, exec_args: [], ws_c_uri: "ws://0.0.0.0/", linemode_strip_newlines: false, linemode_strict: false, origin: None, custom_headers: [], custom_reply_headers: [], websocket_version: None, websocket_dont_close: false, one_message: false, no_auto_linemode: false, buffer_size: 65536, broadcast_queue_len: 16, read_debt_handling: Warn, linemode_zero_terminated: false, restrict_uri: None, serve_static_files: [], exec_set_env: false, reuser_send_zero_msg_on_disconnect: false, process_zero_sighup: false, process_exit_sighup: false, socks_destination: None, auto_socks5: None, socks5_bind_script: None, tls_domain: None, tls_insecure: false, headers_to_env: [], max_parallel_conns: None, ws_ping_interval: None, ws_ping_timeout: None }
[INFO  websocat::stdio_peer] get_stdio_peer (async)
[INFO  websocat::stdio_peer] Setting stdin to nonblocking mode
[INFO  websocat::stdio_peer] Installing signal handler
[INFO  websocat::ws_client_peer] get_ws_client_peer
[INFO  websocat::stdio_peer] Restoring blocking status for stdin
websocat: WebSocketError: Received unexpected status code
[INFO  websocat::stdio_peer] Restoring blocking status for stdin
websocat: error running

Attempt 5: ws://165.227.233.168/api/v1/connection

By this point, it seems like a case of "does it work at all?!", so here's proof it does!

Outcome: Connection opens, closes when I send it junk.

$ websocat -v ws://165.227.233.168/api/v1/connection
[INFO  websocat::lints] Auto-inserting the line mode
[INFO  websocat::sessionserve] Serving Line2Message(Stdio) to Message2Line(WsClient("ws://165.227.233.168/api/v1/connection")) with Options { websocket_text_mode: true, websocket_protocol: None, websocket_reply_protocol: None, udp_oneshot_mode: false, unidirectional: false, unidirectional_reverse: false, exit_on_eof: false, oneshot: false, unlink_unix_socket: false, exec_args: [], ws_c_uri: "ws://0.0.0.0/", linemode_strip_newlines: false, linemode_strict: false, origin: None, custom_headers: [], custom_reply_headers: [], websocket_version: None, websocket_dont_close: false, one_message: false, no_auto_linemode: false, buffer_size: 65536, broadcast_queue_len: 16, read_debt_handling: Warn, linemode_zero_terminated: false, restrict_uri: None, serve_static_files: [], exec_set_env: false, reuser_send_zero_msg_on_disconnect: false, process_zero_sighup: false, process_exit_sighup: false, socks_destination: None, auto_socks5: None, socks5_bind_script: None, tls_domain: None, tls_insecure: false, headers_to_env: [], max_parallel_conns: None, ws_ping_interval: None, ws_ping_timeout: None }
[INFO  websocat::stdio_peer] get_stdio_peer (async)
[INFO  websocat::stdio_peer] Setting stdin to nonblocking mode
[INFO  websocat::stdio_peer] Installing signal handler
[INFO  websocat::ws_client_peer] get_ws_client_peer
[INFO  websocat::ws_client_peer] Connected to ws
hello, world!
[INFO  websocat::sessionserve] Reverse finished
[INFO  websocat::sessionserve] Reverse shutdown finished
^C[INFO  websocat::stdio_peer] Restoring blocking status for stdin

So I'm not exactly sure what to make of this! I can't see any reason the wss:// connections would behave any differently, but maybe I'm missing something!

I'll stick to ws:// in the meantime, but this would be nice to resolve anyhow.

1. go to https://little-printer-claim-code.netlify.app/
2. copy the claim code
3. go to http://littleprinter.nordprojects.co/
4. enter the claim code, give it a name, press "Claim printer"
5. You're redirected to the home page and the printer is not added; no error message is displayed.

Hello,
thank you for the https://littleprinter.nordprojects.co
I was running a local fork of kpeeem modifications (https://github.com/mazhead/sirius) but twitter Oauth stopped working for me and currently I was unable to modify it to start working.

I see yours is still working but in this repo I do not see any modifications. Are you releasing your modifications or keeping them?

In final my questions (hence the issue):

1. Are you able to release any modifications to this repo?
2. Would you consider adding modifications from kpeeem (picture web printing for example)?

I'm investigating some downtime on our Heroku instance that started yesterday…

I just managed to fix a BERG Cloud bridge and thought it was interesting so wanted to document it.

My bridge hasn't been working for a while now. The device would power on, but periodically reboot, and the LP couldn't connect.

I could SSH in, but since the filesystem is mounted RO, it was hard to see how software was the culprit. I eventually managed to get an error message by commenting out the reboot in /usr/bin/oneshot_bergcloud_bridge.sh, waiting for the system-run invocation of that to finish, and then running it myself over an SSH channel. The output looked like this:

Remounting RW
Traceback (most recent call last):
  File "PKGTMP.35950/usr/local/bergcloud-bridge/updater.py", line 5, in <module>
  File "/usr/lib/python2.7/urllib2.py", line 94, in <module>
  File "/usr/lib/python2.7/httplib.py", line 79, in <module>
  File "/usr/lib/python2.7/mimetools.py", line 11, in <module>
  File "/usr/lib/python2.7/rfc822.py", line 74, in <module>
ImportError: dynamic module does not define init function (inittime)
Remounting RO
Finished updates
Loading override URL
Running compiled BERG Cloud daemon
Traceback (most recent call last):
  File "PKGTMP.35950/usr/local/bergcloud-bridge/weminuche_bridge.py", line 10, in <module>
  File "PKGTMP.35950/usr/local/bergcloud-bridge/api.py", line 4, in <module>
ImportError: dynamic module does not define init function (inittime)
Unclean exit. Remaining daemon restart count is now 4
Remounting RW
Traceback (most recent call last):
  File "PKGTMP.35950/usr/local/bergcloud-bridge/updater.py", line 5, in <module>
  File "/usr/lib/python2.7/urllib2.py", line 94, in <module>
  File "/usr/lib/python2.7/httplib.py", line 79, in <module>
  File "/usr/lib/python2.7/mimetools.py", line 11, in <module>
  File "/usr/lib/python2.7/rfc822.py", line 74, in <module>
ImportError: dynamic module does not define init function (inittime)
Remounting RO
Finished updates
Loading override URL
Running compiled BERG Cloud daemon
Traceback (most recent call last):
  File "PKGTMP.35950/usr/local/bergcloud-bridge/weminuche_bridge.py", line 10, in <module>
  File "PKGTMP.35950/usr/local/bergcloud-bridge/api.py", line 4, in <module>
ImportError: dynamic module does not define init function (inittime)
Unclean exit. Remaining daemon restart count is now 3
Remounting RW
...

It continued like that. (I don't like that it's constantly remounting RW to try to update itself, I'm gonna remove that.) But also, we see this strange error from Python:

Traceback (most recent call last):
  File "PKGTMP.35950/usr/local/bergcloud-bridge/updater.py", line 5, in <module>
  File "/usr/lib/python2.7/urllib2.py", line 94, in <module>
  File "/usr/lib/python2.7/httplib.py", line 79, in <module>
  File "/usr/lib/python2.7/mimetools.py", line 11, in <module>
  File "/usr/lib/python2.7/rfc822.py", line 74, in <module>
ImportError: dynamic module does not define init function (inittime)

Some built-in Python modules are defined as native code, in library files. This one was in /usr/lib/python2.7/lib-dynload/time.so. I pulled it to my laptop, and compared it with the same file from berg-bridge-dump.

Somehow that file has had some bytes zero'd out. I have to think that this is hardware failure, that byte offset aligns with a 4kB block size, so some portion of the flash chip has lost its data.

I copied back over the berg-bridge-dump version, (thanks again @kpeeem) and the bridge is working again.

We occasionally come across LPs whose bridges just don't boot - if you connect a UART, sometimes you can see uBoot start, then it dies even before Linux can start. I now suspect that flash corruption is the cause here too. I wish there was a way to reflash these chips. Maybe via JTAG? I'm out of my depth at that point. Maybe somebody knows.