@silentworks you may be interested In the new isomorphic svelte todo-mvc app. Sorry for being late, have been busy lately!
@silentworks it could be compatible (if you wanted to make it work you could look at a koa adapter and a Rill adapter would be very similar.). I personally ran into issues with it (not integration with Rill) so liked to manually setup my oauth. I could revisit making a middleware for it though.
Some of the documentation looked a little out of data to me.
I'm gonna hop off of Gitter now but feel free to shoot me an email at me@evanhahn.com or we can discuss things on the PRs.
:wave:
Nvm @DylanPiercey I was able to work around it by following this:
https://stackoverflow.com/a/24929146/4931825
https://stackoverflow.com/a/24929146/4931825
@eudp you use
res.set https://github.com/rill-js/rill/blob/master/docs/api/response.md#ressetfield-value
Hi @DylanPiercey we are having some issues with rill-session when running the app on chrome. Basically, when you refresh the page or open a new tab the session gets lost and logs the user out. This is not happening on firefox, safari, or any other browser. Can you help?
We managed to get some logs while refreshing the browser while logged in on /some-route
chrome:
@rill/session:28 - req.pathname: /some-route
@rill/session:68 - rill_auth.value: undefined
<-- GET /some-route
--> GET /some-route 302 6ms -
@rill/session:28 - req.pathname: /logout
@rill/session:68 - rill_auth.value: undefined
<-- GET /logout?redirect=/some-route
--> GET /logout?redirect=/some-route 302 8ms -
@rill/session:28 - req.pathname: /login
@rill/session:68 - rill_auth.value: undefined
<-- GET /login?redirect=/some-route
--> GET /login?redirect=/some-route 200 16ms -
user disconnected
@rill/session:28 - req.pathname: /__rill_session__
@rill/session:40 - reading cache
a user connectedfirefox:
@rill/session:28 - req.pathname: /__rill_session__
@rill/session:46 - setting cache
user disconnected
@rill/session:28 - req.pathname: /some-route
@rill/session:68 - rill_auth.value: {
_id: '6015878d...',
token: 'eyJ0eX...'
}
<-- GET /some-route
--> GET /some-route 200 213ms -
@rill/session:28 - req.pathname: /__rill_session__
@rill/session:40 - reading cache
a user connected
@mikemacdonald123 there are three possible issues:
- @rill/session used a "beforeunload" handler to persist session data which browsers have gradually stopped supporting. I just released a new major version
@rill/session@11.0.0which switches to use more modern apis, you should try that. - Could also be that a middleware in your application is causing a redirect or something is preventing the @rill/session middleware from executing.
- Possible that you are clearing cookies some way, and or viewing the page with cookies disabled.
Hi @DylanPiercey we tried the new version
@rill/session@11.0.0 and the user gets logged out when reloading on Chrome. On Firefox the user also gets logged out and the following error is thrown:Error: bad content-type header, unknown content-type: text/plain;charset=UTF-8
at IncomingForm._parseContentType (node_modules/formidable/lib/incoming_form.js:293:15)
at IncomingForm.writeHeaders (node_modules/formidable/lib/incoming_form.js:144:8)
at IncomingForm.parse (node_modules/formidable/lib/incoming_form.js:112:8)
at node_modules/@rill/body/server/index.js:82:8
at new Promise (node_modules/core-js/modules/es6.promise.js:177:7)
at parse (node_modules/@rill/body/server/index.js:61:10)
at parseBody (node_modules/@rill/body/server/index.js:39:12)
at dispatch (node_modules/@rill/chain/src/index.ts:46:38)
at node_modules/@rill/chain/src/index.ts:46:52
at node_modules/@rill/static/server/index.js:29:16
at run (node_modules/core-js/modules/es6.promise.js:75:22)
at node_modules/core-js/modules/es6.promise.js:92:30
at flush (node_modules/core-js/modules/_microtask.js:18:9)
at processTicksAndRejections (node:internal/process/task_queues:78:11)
I think there's one other issue. It's related to performance and shouldn't have an end user impact. Going to see what I can do.
@DylanPiercey just tried
11.0.2 and it's working again on firefox but not on chrome (no errors though). I also checked and the rill_session cookie is there on both browsers. I looked in the network tab of dev tools while reloading to try to find any difference and on firefox there is a POST followed by a GET to __rill_session__, on chrome there is an incomplete request and then GET to __rill_session__. Do you know what could be happening there? Thanks for your response!
@robertobarretog looks like there's still a race condition with using sendBeacon. I'm somewhat out of ideas, ultimately the goal of this module is to persist the session with the server once the browser exits but I think reliable ways to do that (at least before the next navigation) have been disabled by browsers. So I just got out another patch of
@rill/session which instead persists the session at the end of each client side navigation. It's not quite as efficient, but should work fine.
Thanks! @DylanPiercey I tried the latest version and the sessions are working on Chrome, Firefox and Safari. I'm only seeing an error on Safari but it seems to be because the
@rill/loader cache is too large in our app, the session still works though. Beacon API cannot load http://localhost:3002/__rill_session__. Reached maximum amount of queued data of 64Kb for keepalive requests.
Hey @DylanPiercey sorry to bother you again, after testing the latest
@rill/session we are experiencing an issue on safari which is happening seemingly at random: sometimes when entering the app or reloading the browser the app doesn't respond to user interaction, as if it was a cached view only, in the browser console only connected to the server is logged. Reloading the app a few times can get it to work and in that case the browser console shows:connected to the server
<-- GET /settings
--> GET /settings 200 7,947ms@rill/session@11.0.4