strophe failed to connect openfire by websocket - websocket

OF version:3.9.1, I can use pidgin to log on.
When using strophe.js, I tried BOSH first, but it fails, probably I didn't get apache settings right. Then I decide to try websockets, and this is my preferred option, however, I got the following error message:
WebSocket connection to 'ws://ikan.tk:7070/ws/server' failed: WebSocket is closed before the connection is established.
then the status is "connecting" always.
Questions:
what's the URL for websocket? using http-bind port (7070), or the client port (5222)? Any path (like /ws/server) to be followed ?
I'm using OF 3.9.1 on windows, no plugin installed. Does OF 3.9.1 support WS by default, or I have to install some plugin, or there's some configuration items I need to do?
Thanks in advance!

AFAIK,
1) The URL for websocket on OpenFire is ws://of-server:7070/ws with default configuration (see below).
2) You need to install the "WebSockets Plugin" plugin for OpenFire, then you can configure the path of the websocket ("ws" is default) in properties page under the "Server > WebSockets" tab.

Related

Mosquitto no websocket connection since version 02.0.12 (Windows specific)

today I wanted to set up a simple mosquitto server on my windows machine for testing.
I am using "MQTT Explorer" for convenience and downloaded the latest 2.0.14 mosquitto binaries for windows (I am using Windows 10).
However I am unable to connect to my local server with Mosquitto 2.0.14, 2.0.13 and 2.0.12.
My connection is successful with 2.0.11, 2.0.10, 2.0.9a and 2.0.7 but these versions only work when I also have a standard http listener in the config (which I do not want since later on I only want one wss listener).
This is the config I am using:
allow_anonymous true
#HTTP listener
listener 1883
#Websocket standard listener
listener 9001
protocol websockets
This is the server output I get when using 2.0.14, 2.0.13 or 2.0.12 after my connection failed:
And this is the output when using 2.0.11, 2.0.10, 2.0.9a or 2.0.7 but without the http listener in the config:
Can anyone reproduce this behaviour or tell me where I messed up?
As per the comments I was able to duplicate the issue with Mosquitto 2.0.14 and an issue has been raised.
A workaround is to add socket_domain ipv4 into the configuration - e.g.
allow_anonymous true
listener 9001
protocol websockets
socket_domain ipv4
I came across option in this issue and it does appear to fix the issue. Note that I have not looked into why this fixes the issue so this should be considered a temporary workaround until the issue mentioned above is updated.

Using a proxy that requires authentication with pybliometrics

I am using pybliometrics, a Python interface to the Scopus API, to download the abstracts of some papers.
Unfortunately Scopus only works inside the network of the university that subscribed to it. I am currently at home and whenever I try to download something using pybliometrics it gives me the following error:
pybliometrics.scopus.exception.Scopus401Error: The requestor is not authorized to access the requested view or fields of the resource
I need to use my university's proxy in order to enter the internet with the IP address of my university. The proxy has a WPAD configuration file available, but I fail to realize how to use it with pybliometrics. The pybliometrics documentation says to add a block in the configuration file like this:
[Proxy]
ftp = socks5://127.0.0.1:1234
http = socks5://127.0.0.1:1234
https = socks5://127.0.0.1:1234
But this proxy requires authentication. How can I specify the proxy username and password?
EDIT: I have tried setting up the block in config.ini like:
[Proxy]
ftp = http://username:password#proxy.thing.it:8080
http = http://username:password#proxy.thing.it:8080
https = http://username:password#proxy.thing.it:8080
but it still fails with the following error message:
requests.exceptions.ProxyError: HTTPSConnectionPool(host='api.elsevier.com', port=443): Max retries exceeded with url: /content/abstract/scopus_id/84983158344?view=META_ABS (Caused by ProxyError('Cannot connect to proxy.', OSError('Tunnel connection failed: 407 Proxy Authentication Required')))
From our perspective the API will work via a proxy as long as the proxy is configured correctly. I would suggest you speak to the provider of the proxy to see if they can help.
We don't have specific instructions on how to use APIs with a proxy (as there are many potential different versions and potential configurations); however, the general instructions are here:
https://service.elsevier.com/app/answers/detail/a_id/29026/supporthub/elsevieraccess/
To me your new proxy block looks suspicious. It funnels ftp and https requests through the http as well. Maybe try ftp and https as protocols in the corresponding sections.
The other solution is to ask Scopus Integration Support for an InstToken, which you use instead of a proxy. You then specify the InstToken in the configuration file as well.
The problem was that my proxy requires DigestAuth rather than BasicAuth.

IBM WAS sslSocket.getEnabledProtocols() issue

We have a single installation of WAS(8.5.5.10), with multiple clusters(JVMs). We enabled TLS1.2 on one of the JVMs, (say JVM1). But when I run the code sslSocket.getEnabledProtocols(), it gives me supported protocols=[TLSv1], which is V 1.0. My application runs on Java 1.7.
When I check in Security > SSL certificate and key management, and under Related Items, click SSL configurations. ( such as CellDefaultSSLsetting , NodedefaultSSLsetting and any other SSLConfig), it shows 'TLS' as the protocol, under QoP settings.
But when I check in SSL certificate and key management > Manage endpoint security configurations > jvm1_cluster, it shows 'TLS1.2' as SSL configuration.
From IBM forums, I came to understand that it is possible to enable TLSV1.2 at only one cluster. and need to use jssehelper to specify an outbound ssl configuration.
Tried following the link on how to programmatically specifying an outbound SSL configuration using JSSEHelper API. https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/tsec_ssloutconfiguseJSSE.html
but I still could not get it to work. When I print the properties, I can see protocol as TLSV1.2 (com.ibm.ssl.protocol = TLSv1.2). Application uses com.ibm.jsse2.SSLSocketFactoryImpl for ssl socket provider.
To give you some background, am trying to connect to APNS using okhttp3 library. Am adding these properties, at the place where I create the socket connection. And after the socket is created, when I do sslSocket.getEnabledProtocols(), it gives me supported protocols=[TLSv1], which is V 1.0.
Since it tries to connect via TLS1, it gives javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure, when trying to establish connection to APNS. I have the certificate added to was store already and the firewall rules are in place as well, to allow the connection.
Error:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at com.ibm.jsse2.j.a(j.java:23)
at com.ibm.jsse2.j.a(j.java:21)
at com.ibm.jsse2.qc.b(qc.java:465)
at com.ibm.jsse2.qc.a(qc.java:451)
at com.ibm.jsse2.qc.h(qc.java:759)
at com.ibm.jsse2.qc.a(qc.java:353)
at com.ibm.jsse2.qc.startHandshake(qc.java:800)
Pls guide me on how to fix the issue. Thanks.

Change path of RabbitMQ WebSocket MQTT endpoint?

I am running a RabbitMQ instance that provides MQTT over websockets via the rabbitmq_web_mqtt plugin.
For legacy reasons, I need to support a non-default WebSocket URL.
I saw in the documentation it is possible to change the port via the { port, 1234 } config, but I could not find any way to change the WebSocket URL. It is currently set to the default path of /ws
Is it possible to change the WebSocket URL without modifying the plugin?
This has been made configurable back September 2018. See already mentioned ticket.
Add line:
# echo 'web_mqtt.ws_path = /mqtt' >> /etc/rabbitmq/rabbitmq.conf
# service rabbitmq-server restart
Now being accessible by (compliant) MQTT Clients. For instance at:
ws://192.168.210.84:15675/mqtt
UPDATE: RabbitMQ now allows configuration of the WebSocket URL. See this answer.
After some research, I found out that the path is not configurable

How to expose a tornado server serving websockets on dotcloud to the www?

I am trying to install the IPython html notebook server
on dotCloud. The IPython server uses tornado with websockets (and other internal communications using zeromq on tcp sockets).
Hhere's my dotcloud.yml:
www:
type: custom
buildscript: builder
ports:
nbserver: tcp
I am following the custom port recipes given here and here. As the logs show, I run the tornado server on 127.0.0.1:$DOTCLOUD_WWW_NBSERVER_PORT:
/var/log/supervisor/www.log:
[NotebookApp] The IPython Notebook is running at: 'http://127.0.0.1:35928/'
[NotebookApp] Use Control-C to stop this server and shut down all kernels.
But when I push, the dotCloud CLI tells me:
WARNING: The service crashed at startup or is listening to the wrong port. It failed to >respond on port "nbserver" (42801) within 30 seconds. Please check the application logs.
...
Deployment finished. Your application is available at the following URLs
No URL found. That's ok, it means that your application does not include a webservice."
There's nothing on my-app.dotcloud.com or my-app.dotcloud.com:DOTCLOUD_WWW_NBSERVER_PORT
What am I missing here? Thanks for your help.
UPDATE
Issue solved. The usual HTTP port works fine with websockets so the custom port recipes are not required. This is my new dotcloud.yml:
www:
type: custom
buildscript: builder
ports:
web: http
works with the following in ipython_notebook_config.py:
c.NotebookApp.ip = '*'
This makes it so that the tornado webserver listens to all ip addresses.
WARNING: setup security and authentication first!
See Running a Public Notebook Server for more information.
Glad you got it working!
In the future, and for other readers, you actually want your app to listen on $PORT_NBSERVER and then connect to it on DOTCLOUD_WWW_NBSERVER_PORT. $PORT_NBSERVER is the local port while the latter is the port that's exposed to the outside world through our routing/NAT layer.
If you have any other issue, don't hesitate to reach out to us at http://support.dotcloud.com
Source: I'm a dotCloud employee.

Resources