this.userId sometimes null in protected function on server

I’m having an issue:

I have been reading through the issues concerning the “this.userId null in protected” function for quite abit, but I’m not getting this solved.

On my dev machine, I’m not having this issue, however in production, for some users the issue persists. On all my machines, regardless if chrome (or chrome mobile), edge or firefox, I do not have this issue. Other users have this issue in safari, firefox and chrome and chrome mobile.

I have checked with one of the users that have this issue, that the ‘x_mok’ cookie is set.

I have tried using transport http as well as ddp.

I have added additional logging in the protected function as follows:

const params = this.request.cookies;
const sessionId = String(params.x_mtok);
const userId =
        Meteor.server.sessions.get(sessionId) &&
        Meteor.server.sessions.get(sessionId).userId
            ? Meteor.server.sessions.get(sessionId).userId
            : null;
console.warn(params);
console.warn(sessionId);
console.warn('this.userId,', this.userId);
console.warn('userId,', userId);

which returns the following outcome (given that the problem is present)

[Object: null prototype] {}
undefined
this.userId, null
userId, null

Version of Meteor-Files: 1.13.0* Version of Meteor: METEOR@1.8.1

My package file:

meteor-base@1.4.0             # Packages every Meteor app needs to have
mobile-experience@1.0.5       # Packages for a great mobile UX
mongo@1.6.2                   # The database Meteor supports right now
reactive-var@1.0.11            # Reactive variable for tracker
tracker@1.2.0                 # Meteor's client-side reactive programming library

standard-minifier-js@2.4.1    # JS minifier run for production mode
es5-shim@4.8.0                # ECMAScript 5 compatibility for older browsers
ecmascript@0.12.4              # Enable ECMAScript2015+ syntax in app code
shell-server@0.4.0            # Server-side component of the `meteor shell` command

accounts-base
accounts-ui@1.3.1
accounts-password@1.5.1
useraccounts:bootstrap
alanning:roles
ostrio:files
mdg:validated-method
akryum:vue-component
fortawesome:fontawesome
seba:minifiers-autoprefixer
akryum:vue-router2
akryum:vue-sass
akryum:vue-blaze-template
msavin:mongol
vuejs:blaze-integration
aldeed:template-extension
matb33:collection-hooks
momentjs:moment
underscore@1.0.10
check@1.3.1
reywood:publish-composite
static-html
akryum:vue-less
fourseven:scss
jquery
email
aldeed:collection2@3.0.0
mrt:gsap

ros:publish-counts
littledata:synced-cron
http
meteortesting:mocha
practicalmeteor:faker
lmieulet:meteor-coverage
jackyqiu:meteor-jvectormap
percolate:migrations

The client side logs do not show anything out of the ordinary.

The server side logs of course show the following:

[FilesCollection._checkAccess] WARN: Access denied!

Thanks in advance and have a nice day! 😃

[Lickshotz]

As you suggested, redirecting incoming requests to example.com solved the issue.

Thank you!

[menelike]

Every request is made to www.example.com, apart from the one to /cdn, that one is to example.com.

Well, I think that this is exactly your problem. https://www.thinktecture.com/en/identity/samesite/samesite-in-a-nutshell/

On a general note, you should just use one domain if applicable to make your life easier. https://docs.meteor.com/environment-variables.html#ROOT-URL needs to match as well.