Open green3g opened 6 years ago
As discussed in the done-ssr bug, I think this might be fixable by providing our own setJWT
method that prevents saving the internal state. In that case it would always get the JWT from the cookie. I don't know enough about connect to know if this is feasible, can we provide our own Passport class some how?
I'm not sure if we should just prevent setJWT from saving the internal state though. app.accessToken
gets set so that service hooks can run correctly on the client. If, for instance I prevent the app from ever setting accessToken
none of my service requests will work because the hooks will prevent this.
In my test app you can see the issue arise if you add this to the application.js set method:
(public/node_modules/@feathersjs/feathers/lib/application.js:35
)
set (name, value) {
if(name === 'accessToken' && window.doneSsr){
debugger;
return this;
}
this.settings[name] = value;
return this;
},
If you add that does it fix the cookie issue?
Yes, that does fix the issue, where users are getting mixed up. But donejs is unable to access any data from the api's since its not properly authenticated in feathers.
Okay, I think I have a solution. Its a relatively simple fix in feathers-authentication.
In populate-access-token
,
Object.assign(hook.params, { accessToken: app.get('storage').getItem(app.passport.options.storageKey) });
in passport
:
remove references to app.set and app.get accessToken
This line prevents can-connect from ever authenticating in done-ssr, therefore pages are rendered without authentication, even if user's cookies are provided to done-js.