Move service key setting to main module

Were you able to resolve this issue? I am currently facing an "Invalid Service Key" error despite maintaining the settings in nodejs.config file and settings.php.

I had the same error and fixed it by enabling the Nodejs Config submodule of Nodejs integration. In the configuration builder, I added the same info as my nodejs.config.js and saved the form. Then it worked. I didn't replace my nodejs.config.js with the new details.

I can confirm this bug on a fresh setup too.
There is 2 work around I'm aware of at the moment :
- The first is described at #4.
- The second is to leave an empty key on the config file.

I'll have a go more seriously on that issue soon.
++

The problem is quite simple.
For every message handled by the backend the first thing that the code performs is to check the service key.

function nodejs_message_handler() {
  if (!isset($_POST['serviceKey']) || !nodejs_is_valid_service_key($_POST['serviceKey'])) {
    drupal_json_output(array('error' => 'Invalid service key.'));
    drupal_exit();
  }
...

The function that performs this check is fairly simple :

function nodejs_is_valid_service_key($service_key) {
  return $service_key == variable_get('nodejs_service_key', '');
}

If you didn't enable your config module on and didn't have a go trought it, the "nodejs_service_key" variable is not set at all !
This is leading to compare the default '' string to your actual string defined in your configuration file.
This is also explaining why letting a blank string in your configuration file is actually working.

=> I suggest to add a 'secret key' field to the main configuration form located at admin/config/nodejs/config
And to provide an alert to the end user when an invalid key problem is raised.
Eventually it would be necessary to strip out the 'secret key' field from the config module.

If that make sense, I would submit a patch going that way.
++

Here's a patch that solve this issue.
It also resolve issue 2181111.

There was a confusion with the service key into the nodejs_config module.
This module was indeed setting the 'nodejs_service_key' variable where it should have just set a config variable for the configuration builder only. There was also no way to set the 'nodejs_service_key' variable without enabling and run the nodejs_config setting form.
This leaded to the error and the behavior described above.

Well... basically here's the full details of what this patch does :
1) Bring a service key field in the main nodejs config form. This field set the real nodejs_service_key variable that will be actually compared with the one stored in the nodejs.config.js.

2) Spread the 'nodejs_service_key' variable from the nodejs_config form. This builder is now defining a 'nodejs_config_service_key' just like it does for others fields (host => nodejs_config_server_host, port => nodejs_config_server_port, protocol => nodejs_config_server_protocol...). Variables defined in this form are just helper variables. They are not used in any way in the real communication process. It is now not different for the service key.

3) Help the end user monitor that something could be wrong with the service key. The http request used to be checked for errors before returning the message. The truth is, a correct http message could still contain an error into the response itself (it's the case when service key isn't matching). The code in this patch also checks for such an error and display a message to the end user if this happens. It also prevents php errors in the case the message is still returned with a service key error.

4) Performs clean uninstall of both modules (main nodejs and nodejs_config).

Tested and approved here.
Cheers !

The latest version of the module will hint at the service key being incorrect on the status page if the connection test fails.
That said, as you pointed out, node_config module does need to be enabled in order to configure the service key. Because that submodule is supposed to be a configuration builder for the backend, it is definitely not the most suitable place for the service key. I'll review your patch and commit a fix. Thanks for submitting.

This issue has been addressed. Thanks for the patch. I have made the following changes:
- I skipped the changes in Nodejs::httpRequest. This is a low level method, and we don't want it to put up messages. It wouldn't be appropriate for site visitors to see an error about the service key being invalid. In addition, the error returned by the http call might be needed by the caller function so we don't want to throw that away here.
- I made the service key setting read-only in the configuration builder. There is no point in being able to set it in two different places.