Hi @dariofiore, you may add CORS capability to the socket.io input channel by providing the Server() with the cors_allowed_origins keyword argument here:
Hello, how are you ? I wonder to know how to pass this keyword to socketio.Server. What files should I change ? I tried to put the cors_allowed_origins in credentials.yml file o rasa at the socketio session but it didnt works.
I noticed the same with Rasa X - regardless if you specify cors * or not, it doesn’t work. Not a problem though with Rasa server (at least not with 1.1.x).
Just curious why not fix this error? I really don’t like the idea of having to hack the rasa code after installation. If the rasa run CLI documentation states i can pass --cors “*” why would the websocket channel (without any note about it) be excluded, where it’s a simple 2nd parameter into the method.
sio = AsyncServer(async_mode=“sanic”)
@erohmensing FYI Maybe at least add do documentation to state that websocket currently doesn’t support the --cors param from rasa run. I think rasa x also suffers from this. My Rasa Version is 1.1.4 and pytho 3.6.8, Ubuntu 16.04 and Debian 9
@akelad and @Tobias_Wochinger We upgraded to Rasa 1.2.9 (using 1.2.9 tagged Docker rasa image with python 3.6.9) and picked up a “fix”, which now even broke Firefox XHR (before only Chrome was complaining, but could get local dev done in Firefox) .
While the fix does not outright cause “origin not allowed” error, but it causes browsers to complain about the following:
What happens is that the UI keeps trying due to missing header error:
2019-09-23 18:31:04 DEBUG rasa.model - Extracted model to '/tmp/tmp0mpz4mxe'.
2019-09-23 18:31:04 DEBUG pykwalify.compat - Using yaml library: /usr/local/lib/python3.6/site-packages/ruamel/yaml/__init__.py
2019-09-23 18:31:09 INFO engineio.server - ff77025bcce544dc83dacb30c2ee2a7f: Sending packet OPEN data {'sid': 'ff77025bcce544dc83dacb30c2ee2a7f', 'upgrades': ['websocket'], 'pingTimeout': 60000, 'pingInterval': 25000}
2019-09-23 18:31:09 DEBUG rasa.core.channels.socketio - User ff77025bcce544dc83dacb30c2ee2a7f connected to socketIO endpoint.
2019-09-23 18:31:09 INFO engineio.server - ff77025bcce544dc83dacb30c2ee2a7f: Sending packet MESSAGE data 0
2019-09-23 18:31:14 INFO engineio.server - b70b1bbc9b93413db19c6d57e278f9be: Sending packet OPEN data {'sid': 'b70b1bbc9b93413db19c6d57e278f9be', 'upgrades': ['websocket'], 'pingTimeout': 60000, 'pingInterval': 25000}
2019-09-23 18:31:14 DEBUG rasa.core.channels.socketio - User b70b1bbc9b93413db19c6d57e278f9be connected to socketIO endpoint.
2019-09-23 18:31:14 INFO engineio.server - b70b1bbc9b93413db19c6d57e278f9be: Sending packet MESSAGE data 0
The only true fix that ever worked was this one:
I.e. set cors_allowed_origins='’ or enhance the code to pass the --cors "" into AsyncServer.
There are newer comments in the thread that indicate that it’s not behaving well still:
Can we just not pass in the rasa run --cors param into AsyncServer? I tried setting the AsyncServer 2nd parameter to both * and “http://localhost:8080” and both work. So we can propagate that from command line, that would maybe finally fix this problem.
It is only that ‘*’ parameter into AsyncServer that will cause it to return the proper header allowing the request:
Unless I am missing something? @Tobias_Wochinger How did you make it work?
@Serge have you tried also adding the --enable-api flag to your run command? That was needed for the version you’re referring to. With the latest release now I think you can ommit that flag and it should work fine
I built a new environment with Fedora 29 Server, installed Rasa and launched it. I can launch Rasa X and/or Rasa (rasa run -m models --enable-api --endpoints endpoints.yml --cors “*”) and get a response from both Rasa X and Rasa Core in my browser. However, when trying to use a NodeJS client (rasa-api - npm) I keep getting a cors error.
First question: How do I set a fixed IP for everything?
Second question: The api calls for the following (I realize the api is not created by Rasa). Rasa(’’, ‘’,’’, ‘’). Where can I get the Project Name and Server Access Token?
EDIT: I did try to change the line in socket.py from
@cafarmer are you still having this issue? If yes, would you be able to format your post and also provide some more details, e.g. what request you’re sending?
I am still having the problem with the rasa-api component, but I was able to get around it by leveraging the “request” component in my React application. I am able to match intent through the model and communicate with the Webhooks api (‘http://192.168.207.223:5005/webhooks/rest/webhook’). I think there was a difference on how the rasa-api component tried to talk to Rasa that would not work with without a CORS exception/host specified. So I am not really sure I am on the right track, but at least I got something to work.
Thanks!
-Chris
Like this:
Model to match intent
const Request = require('request');
var options = {
method: 'POST',
url: 'http://192.168.207.223:5005/model/parse',
body: { "text": this.state.queryString },
json: true };
Request(options, function (error, response, body) {
if (error) throw new Error(error);
console.log('rasa matched intent: ' + body.intent.name);
});
Webhooks to converse
const Request = require('request');
var options = {
method: 'POST',
url: 'http://192.168.207.223:5005/webhooks/rest/webhook',
body: {"sender":"John Galt","message":"Hello"},
json: true };
Request(options, function (error, response, body) {
if (error) throw new Error(error);
console.log(body);
});
@akelad I still have on the TODO list to try the --enable-api option with 1.1.4. Doesn’t seem to complain, but i haven’t done a negative test to confirm.
But just upgraded to 1.6.2 and immediately got CORS violation in both chrome and firefox and then setting --cors ‘*’ definitely had an affect and stopped complaining about cors and started working. And in 1.6.2 without the --enable-api
And just to clarify, this is not Rasa X but rather Rasa server (Open Source) and this https and ws communication over websocket channel.