I'm developing a VerneMQ plugin for jwt authentication in which I need to disconnect a client inside the auth_on_publish plugin if it's jwt token is expired.
Is it possible to close a connection inside a plugin hook?
I found the answer on the VerneMQ slack channel, provided by the VerneMQ developer himself:
All the auth_on_x hooks are executed in the MQTT session process, so you can send it a disconnect message like this: self() ! disconnect, and the client will be disconnected.
So, inside the auth_on_publish plugin, when my authentication expires, I just run self() ! disconnect and the client is disconnected as desired.
Note, however, that this is using internals of VerneMQ and is not guaranteed to work forever. Currently no 'official' API exists for this feature.
Related
Working from some time on a sails web application.
So far overcome all issues by hard reading, trial and error.
Recently had to install the app for a close beta test on the client's ec2 free trial instance where it works just fine in development mode.
The app is behind a nginx proxy which listens on the 80 port and redirects to http://server_IP:1337.
CORS and CSRF are enabled, allowOrigins and onlyAllowOrigins are set to the server IP, web domain and localhost in production.js and, security.js and sockets.js.
But when switching to production mode all API requests, except GET, give 403 forbidden.
Tried everything I could find on Google, it simply doesn't work on production but it completely works on development.
If anyone could share a shred of light on this will be greatly appreciated.
EDIT:
Running the app with debug silly, showed this:
A socket is being allowed to connect, but the session could not be loaded. Creating an empty, one-time session to use for the life of this socket connection.
This log often shows up because a client socket from a previous lift or another Sails app is trying to reconnect (e.g. from an open browser tab), but the session indicated by its cookie no longer exists-- because either this app is not currently using a persistent session store like Redis, or the session entry has been removed from the session store (e.g. by a scheduled job or because it expired naturally).
Details:
Error: Session could not be loaded.
at Immediate._onImmediate (/var/www/allscubashops.com/node_modules/sails/lib/hooks/session/index.js:543:42) at processImmediate (internal/timers.js:445:19)
Then I have deleted the old browser cookie and got this:
Could not fetch session, since connecting socket has no cookie in its handshake.
Generated a one-time-use cookie:
sails.sid=s%3APlHbdXvOZRo5yNlKPdFKkaPgVTNaNN8i.DwZzwHPhb1%2Fs9Am49lRxRTFjRqUzGO8UN90uC7rlLHs
and saved it on the socket handshake.
This means the socket started off with an empty session, i.e. (req.session === {})
That "anonymous" session will only last until the socket is disconnected. To work around this,
make sure the socket sends a cookie header or query param when it initially connects.
(This usually arises due to using a non-browser client such as a native iOS/Android app,
React Native, a Node.js script, or some other connected device. It can also arise when
attempting to connect a cross-origin socket in the browser, particularly for Safari users.
To work around this, either supply a cookie manually, or ignore this message and use an
approach other than sessions-- e.g. an auth token.)
Also no new cookie was set.
The apparent conclusion is that somehow in production mode something is wrong with setting the session.
EDIT 2:
The latest find is that if I run the app without nginx proxy, I do not have the forbidden API requests issue but I still have the one related to the session not being created.
I am sure the nginx proxy settins are OK but now I am thinking of implementing the redis way to store sessions instead of the default memory one and see what happens
EDIT 3:
I have implemented the Redis sessions which works both for dev and prod modes.
Still same situation, the ec2 instance without nginx proxy works in production mode while the same files (git replicated) on the ec2 instance with nginx proxy doesn't work in production mode (API requests 403 forbidden) but works great in development mode.
The X-CSRF token is sent, screenshot
The sails error message I get in production (besides the network 403 forbidden error for all requests except GET) is:
A socket is being allowed to connect, but the session could not be loaded. Creating an empty, one-time session to use for the life of this socket connection.
This log often shows up because a client socket from a previous lift or another Sails app is trying to reconnect (e.g. from an open browser tab), but the session indicated by its cookie no longer exists-- because either this app is not currently using a persistent session store like Redis, or the session entry has been removed from the session store (e.g. by a scheduled job or because it expired naturally).
Details:
Error: Session could not be loaded.
at /var/www/example.com/node_modules/sails/lib/hooks/session/index.js:543:42
at Command.callback (/var/www/example.com/node_modules/#sailshq/connect-redis/lib/connect-redis.js:148:25)
at normal_reply (/var/www/example.com/node_modules/machinepack-redis/node_modules/redis/index.js:714:21)
at RedisClient.return_reply (/var/www/example.com/node_modules/machinepack-redis/node_modules/redis/index.js:816:9)
at JavascriptRedisParser.returnReply (/var/www/example.com/node_modules/machinepack-redis/node_modules/redis/index.js:188:18)
at JavascriptRedisParser.execute (/var/www/example.com/node_modules/redis-parser/lib/parser.js:574:12)
at Socket. (/var/www/example.com/node_modules/machinepack-redis/node_modules/redis/index.js:267:27)
at Socket.emit (events.js:193:13)
at addChunk (_stream_readable.js:296:12)
at readableAddChunk (_stream_readable.js:277:11)
at Socket.Readable.push (_stream_readable.js:232:10)
at TCP.onStreamRead (internal/stream_base_commons.js:150:17)
Therefore I assume that the sockets connect but the session is not created.
Redis works OK, I see sessions in it for when in development.
Have you exposed the csrf endpoint and are you making a call to that endpoint first, to get a token, before making further requests? This tipped me up once.
Converse.js successfully makes requests to Prosody bosh but the chat client never actually connects. In the console I can see it hitting the bosh endpoint and after each request it outputs to the console:
"Server did not yet offer a supported authentication mechanism. Sending a blank poll request."
I can hit the bosh endpoint from my browser as well, the proxy pass appears to be working as intended and bosh is running and responding to requests.
Any insight is much appreciated.
I came across this issue as well while using the fullpage demo. The problem was because Prosody was forcing encrypted authentication only for client side.
I recommend going into the config file /etc/prosody/prosody.cfg.lua
Look for the code
-- Force clients to use encrypted connections? This option will
-- prevent clients from authenticating unless they are using encryption.
c2s_require_encryption = true
By default for me this was set to true, change this to false
c2s_require_encryption = false
save it and reboot Prosody
systemctl restart prosody
you could also do
prosodyctl restart
The error message is quite clear. Prosody is not offering a SASL authentication mechanism supported by Converse.
By default Converse supports SCRAM-SHA1, DIGEST-MD5 and PLAIN.
Your XMPP server needs to support one of these.
This question is very specific to FRITZ!Box 7360. I have the lest firmware installed.
I want to configure a sip account from a provider like Elvero. I tried to follow instructions provided at configuring internet telephone. After configuring I do not see any sip connection attempts reaching the sip server and FRITZ!Box complains that it did not get a response from the server.
This means, I cannot receive and make calls through Elvero. Anyone got successful in connecting FRITZ!Box to an external sip provider?
I've followed the guide:
Getting Started with Authentication with Mobile Services .NET for Windows Store
I'm able to run the service locally as long as I don't need to authenticate the user. I can also authenticate the user if I publish the service to Azure. But I want to be able to test and authenticate the user locally. How can this be done?
I'm using Live ID and I have the correct ClientID and ClientSecret set in the Web.config. When I attempt to call LoginAsync from the client the call fails with The request could not be completed. (Method Not Allowed)
** Update 2014-03-20 **
Based on the comments of Carlos and Henrik, I've updated my local service to look exactly like my server instance. I followed Scot Hanselmans excellent guide and now I have my service running locally on port 80 and port 443 with a completely valid SSL certificate. It's even running on the exact same https://xxxx.azure-mabile.net hostname.
With these changes, there is now no configuration difference whatsoever between running the app against my local machine or running it against Azure. I can go to https://xxxx.azure-mabile.net in the browser, get redirected to Live login, sign in, and get redirected back to the service successfully. In the browser it all works. However it still doesn't work in the app.
I attached the debugger, set CLR errors to "break when thrown" and I managed to trap the exception in the service. Here's what I see in the immediate window:
The Response property is not helpful. It does not provide any additional information about the problem.
The only thing that stands out to me is that the app is trying to do a POST to /login/microsoftaccount while the browser would normally be doing a GET at this address (then getting redirected).
** Update #2 2014-03-20 **
After following Henriks guide for remote debugging I was able to load symbols and get a tiny bit more information:
"An existing connection was forcibly closed by the remote host"
The error code is 10054 (WSAECONNRESET) Connection reset by peer.
It appears the Live Authentication server may be forcibly terminating the connection, but only when I'm authenticating with the app. Again, authentication within the browser is fine. This, combined with the fact that /login/microsoftaccount is a POST from the app seems to suggest there is a problem with the authentication token I'm getting back from LiveClient.LoginAsync. I'll do some more digging...
At the moment, it is set up so that you don't need authentication when running locally and access the service from localhost. In this case, anonymous access is let through (this is of course disabled while running in the cloud).
We don't really have a way for your to authenticate locally as redirect URIs won't work (they can't point to localhost as there is not way that Facebook, say, can resolve "localhost").
One option is that we somehow can mock the authentication locally and give you a token without connecting with the various identity providers. I am not sure exactly what that would look like but it is something we can consider.
Henrik
Did you perhaps set Mobile client app: Yes in your Live Connect project? I think that setting is meant to be used with the Live Connect SDK (client) flow, not the browser-based (server) flow. The client flow isn't supported yet with a .NET backend.
You also want to make sure you are using LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount) on the client to trigger the server flow.
I am implementing XMPP service in the browser using BOSH. I use JAXL library. I am able to manage the connection over BOSH to my localhost server (ejabberd). The session is started and the user is authenticated with no problem. However, when I just change the BOSH host to jappix.com, the very first response from the server is only empty body. Even if I repeat the request (according to XEP-206) I still get only empty body so I'm unable to perform any other actions.
So that's my question: Is it possible to use jappix.com to handle my BOSH requests? Are there any limitations? How can I fix this issue? I'll provide more information if needed.
I am the Jappix.com owner!
Your question does not concern our service directly but more likely a node-xmpp-bosh - the BOSH server we are running - bug (?) that you can report on http://code.google.com/p/node-xmpp-bosh/