[FileBot Node] DSM 6.2.4 authentication workaround

[rednoah]

HTTP_X_SYNO_TOKEN: undefined could be a problem if Improve protection against cross-site request forgery attacks is disabled. The new version should be able to work with that setting being either enabled or disabled though. Note that this setting might not come into effect until you sign out / sign in again.

Let's try enabling that, then Sign Out / Sign In in DSM to reset the DSM user session, then open FileBot Node and see if HTTP_X_SYNO_TOKEN: <something> now appears in the logs.

[davemccreath]

rednoah

It was already enabled. However, logged out and then back in again. Log still shows

Code: Select all

{ HTTP_COOKIE: 'id=FL7F7x99WixPyJDacRX-gBVuacX_VOaj3247036GpB8bohytQ3iRG75JIJ32KZ_f4wRF2q0Mr_b4uCalAFkE3M',
  REMOTE_ADDR: '192.168.1.2',
  HTTP_X_SYNO_TOKEN: undefined }

[davemccreath]

Full log below:

Code: Select all

  FILEBOT_TASK_CMD: 'filebot-node-task',
  TERM: 'vt102',
  FILEBOT_CMD_UID: '0',
  SYNOPKG_TEMP_LOGFILE: '/tmp/synopkgmgr.log-filebot-node',
  SYNOPKG_DSM_ARCH: 'apollolake',
  OLDPWD: '/',
  JAVA_OPTS: '',
  FILEBOT_CMD_CWD: '/volume1',
  PATH: '/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin',
  SELF: 'filebot-node',
  FILEBOT_CMD_GID: '0',
  PWD: '/var/packages/filebot-node/target',
  SYNOPKG_PKGDEST: '/volume1/@appstore/filebot-node',
  FILEBOT_NODE_HOST: '127.0.0.1',
  SYNOPKG_PKGVER: '0.4.1',
  SYNOPKG_DSM_VERSION_MINOR: '2',
  SHLVL: '3',
  FILEBOT_CMD: 'filebot',
  SYNOPKG_DSM_VERSION_BUILD: '25556',
  UPSTART_INSTANCE: '',
  UPSTART_EVENTS: 'syno.pkgctl.pkgstart',
  SYNOPKG_PKGNAME: 'filebot-node',
  FILEBOT_NODE_HTTP_PORT: '5452',
  SYNOPKG_DSM_VERSION_MAJOR: '6',
  SYNOPKG_PKGDEST_VOL: '/volume1',
  FILEBOT_NODE_AUTH: 'SYNO',
  UPSTART_JOB: 'pkgctl-filebot-node',
  FILEBOT_NODE_DATA: '/var/packages/filebot-node/target/data',
  FILEBOT_NODE_HTTP: 'YES',
  _: '/usr/local/bin/node' }
USER { UID: 0, GID: 0 }
filebot-node listening at http://127.0.0.1:5452
/usr/syno/synoman/webman/authenticate.cgi
{ HTTP_COOKIE: 'id=u_lGQ4USnHAtrWynGHHesedGfeFcl5CKRthuGhTt47gzlslUHKdpOyX2pIbEq5K3n_c0mIP_MI1aK3DhvnQ_fc',
  REMOTE_ADDR: '192.168.1.2',
  HTTP_X_SYNO_TOKEN: undefined }
/usr/syno/synoman/webman/authenticate.cgi
{ HTTP_COOKIE: 'id=u_lGQ4USnHAtrWynGHHesedGfeFcl5CKRthuGhTt47gzlslUHKdpOyX2pIbEq5K3n_c0mIP_MI1aK3DhvnQ_fc',
  REMOTE_ADDR: '192.168.1.2',
  HTTP_X_SYNO_TOKEN: undefined }
/usr/syno/synoman/webman/authenticate.cgi
{ HTTP_COOKIE: 'id=u_lGQ4USnHAtrWynGHHesedGfeFcl5CKRthuGhTt47gzlslUHKdpOyX2pIbEq5K3n_c0mIP_MI1aK3DhvnQ_fc',
  REMOTE_ADDR: '192.168.1.2',
  HTTP_X_SYNO_TOKEN: undefined }
/usr/syno/synoman/webman/authenticate.cgi
{ HTTP_COOKIE: 'id=FL7F7x99WixPyJDacRX-gBVuacX_VOaj3247036GpB8bohytQ3iRG75JIJ32KZ_f4wRF2q0Mr_b4uCalAFkE3M',
  REMOTE_ADDR: '192.168.1.2',
  HTTP_X_SYNO_TOKEN: undefined }
/usr/syno/synoman/webman/authenticate.cgi
{ HTTP_COOKIE: 'id=FL7F7x99WixPyJDacRX-gBVuacX_VOaj3247036GpB8bohytQ3iRG75JIJ32KZ_f4wRF2q0Mr_b4uCalAFkE3M',
  REMOTE_ADDR: '192.168.1.2',
  HTTP_X_SYNO_TOKEN: undefined }

[rednoah]

Well, in this case, let's see what happens if we disable that setting?

[davemccreath]

Ha! Tried that as well, got the the following error message in the FileBot window:

Code: Select all

{"success":false,"error":"ILLEGAL REQUEST"}

[rednoah]

What's the URL for that page? Did you open the FileBot Node window by clicking on FileBot Node in the DSM UI, or by directly pasting some URL into your browser?

[davemccreath]

rednoa

URL is on the local network: 192.168.1.xx:5001.

Selected the FileBot Node icon from within the DSM UI.

This is with 'Improve protection against cross-site request forgery attacks' NOT selected



And this with 'Improve protection against cross-site request forgery attacks' selected

[rednoah]

That response shouldn't be possible... unless there's a filebot-node reverse_proxy configuration, which can't possibly exist...

Code: Select all

ls -l /usr/local/etc/nginx/conf.d

[davemccreath]

As requested;;

Code: Select all

total 28
-rw-r--r-- 1 root root 122 Apr  7 07:16 dsm.filebot-node.conf
-rw-r--r-- 1 root root  72 May 22 14:59 dsm.ssdp.conf
-rw-r--r-- 1 root root 192 May 22 14:59 dsm.StorageAnalyzer.conf
-rw-r--r-- 1 root root 282 May 22 17:03 dsm.synorelayd.conf
-rw-r--r-- 1 root root   0 May 22 14:58 events.conf
-rw-r--r-- 1 root root   0 May 22 14:58 main.conf
lrwxrwxrwx 1 root root  69 May 22 14:59 www.phpMyAdmin.enable.conf -> /var/packages/phpMyAdmin/target/nginx_conf/www.phpMyAdmin.enable.conf
lrwxrwxrwx 1 root root  68 Mar 30 07:20 www.WordPress.conf -> /var/packages/WordPress/target/synology_added/etc/www.WordPress.conf
-rw-r--r-- 1 root root 460 May 22 15:00 x-accel.VideoStation.conf

Dave

[rednoah]

WTF?!?!


So this entire thread is all about DSM integration no longer working because DSM 6.2.4 package permissions no longer allowing us to create our /usr/local/etc/nginx/conf.d/dsm.filebot-node.conf reverse proxy configuration on install. And yet here you are with that file. I can only assume that it was installed pre-DSM 6.2.4 and then stuck around, because the same permissions that prevent our package from creating that file nowadays would also prevent it from deleting that file if it were to be there already.


TL;DR sudo rm /usr/local/etc/nginx/conf.d/dsm.filebot-node.conf and then restart the machine. That should restore some sanity to the world.

[davemccreath]

And that worked.

Apologies if I was unintentionally at fault.....trying my best!

Regards

Dave

[rednoah]

Apologies if I was unintentionally at fault.....trying my best!

Just a strange side-effect of Synology limiting what packages can and cannot do over time. This issue might very well affect quite a lot of people, possibly every user who had FileBot Node installed before upgrading to DSM 6.2.4 so it's good to know the symptoms and the solution.

[xIntenso]

Version 0.4.1.1 no longer works for me, even after uninstalling and then reinstalling.
I get the following error message:

Code: Select all

{"success":false,"error":"Error: ENOENT: no such file or directory, uv_cwd"}

[rednoah]

Is this a HTTP response you seen in your browser? Or is it a JS error in the console? Is there a call stack attached to that error? Or is this a line from the server-side log? Does the server-side log say anything other than that?



EDIT:

Have you tried restarting your device yet?
viewtopic.php?p=54430#p54430

[xIntenso]

Is this a HTTP response you seen in your browser? Or is it a JS error in the console? Is there a call stack attached to that error? Or is this a line from the server-side log? Does the server-side log say anything other than that?



EDIT:

Have you tried restarting your device yet?
viewtopic.php?p=54430#p54430

You were right, a reboot did the trick!
For the record: It was an error message in the application window inside DSM. It was the only line of text in the window, at the very top left.
Thanks for the quick solution!

[rednoah]

Looks like Stop doesn't actually do anything sometimes, and so the node process keeps running, and with underlying files being deleted on uninstall, it will fail on file system access, and on reinstall prevent the new process from starting since port is already in use. A restart will fix all of that.