Needs review
Project:
Node.js integration
Version:
8.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Feature request
Assigned:
Unassigned
Reporter:
Anonymous (not verified)
Created:
4 Feb 2012 at 17:57 UTC
Updated:
21 Sep 2021 at 20:45 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
jwalz commentedI'm changing the category/priority of this issue as it has more implications than just the auth token. Specifically, this creates a session for anonymous users which can cause caching issues (For me, I'm running into the problem with varnish).
There may be a cleaner way to do this, but I needed a fix right away. All I've done is define a specific token that anon users will use to avoid the need for a session.
Comment #2
moehac commentedSame issue with having Varnish as proxy. This patch worked.
Comment #3
Anonymous (not verified) commentedi think we're taking the wrong approach here, and it seems past-me was also wrong. i do see the use case - creating public channels and allowing access without ever involving drupal and starting a session. some thoughts below.
as it stands now, all access control is handled by drupal. a socket connects with an authtoken, we send that to drupal, and drupal tells server.js what that socket can see.
if we don't have an authtoken which we pass to drupal, how do we decide what that socket has access to? we absolutely don't want to give non-authenticated sockets access to data based on input server.js receives from those sockets.
so, i think we need to implement drupal-controlled public channels. these channels are explicitly public - no access control at all. anyone on the internet can connect to your server.js process and start listening in on whatever is sent to that channel. i'm belabouring the point a bit to make it very, very clear that there is no access control on these channels.
then, we need a global 'allow non-authenticated sockets' switch for server.js. when set, if a socket is created without an authtoken, it is simply subscribed to any 'public' channels.
does that make sense? patches welcome...
Comment #4
Anonymous (not verified) commentedComment #5
moehac commentedIn order to make public channels work for us, in addition to patch #1 (due to caching issues), I also changed the nodejs client-manager.js script to also look for 'sessionId' in preAuthSockets if the message contains a certain parameter. It's not the best way (I'm sure), but at least via Drupal we can control what is available for everyone to see by controlling this parameter's value.
I'm using drupal-node.js@1.0.9.
We use svn, so I'm attaching the patch as a file.
Comment #6
socialnicheguru commentedso is this for the newest version? lib/client-manager.js is not in the newest version of the module
Comment #7
moehac commented@SocialNicheGuru, lib/client-manager.js is part of the npm package here: https://www.npmjs.com/package/drupal-node.js, it's not part of the Drupal module.
Comment #8
joelstein commentedWe also needed a way to integrate Node.js with anonymous users, and the approach from the first patch posted here worked well for us. Here's the Drupal 8 equivalent. I also changed the auth token to "anonymous_user".
Comment #9
joelstein commentedAfter further testing, it seems the patch I posted in #8 prevents authenticated users from receiving the "nodejs_user_UID" token.
This new patch seems to work better for both authenticated and anonymous users.