Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

websocket requests also create a sessions table record #165

Open
aksharj opened this issue Oct 20, 2020 · 6 comments
Open

websocket requests also create a sessions table record #165

aksharj opened this issue Oct 20, 2020 · 6 comments

Comments

@aksharj
Copy link

aksharj commented Oct 20, 2020

HI all,

I have action cable integrated in my application and the websocket end point is pinged after i think every 30 seconds or so.

But this seems to be creating records in the session table, is this the expected behaviour. is there a way i can exclude certain end points from creating session table records.

Also, after login in the same session if i am performing a ajax call, this also creates a record in the sessions table with a unique id but same data. is this the expected behaviour?

Screenshot 2020-10-20 at 10 17 27

any help on this would be really great, many thanks.

@jasonfb
Copy link

jasonfb commented Oct 20, 2020

No, it sounds like the _session_id is not being passed from the front-end to the back end. Use debugging tools to examine if it is being passed from the front end at all.

@aksharj
Copy link
Author

aksharj commented Oct 21, 2020

Hi @jasonfb many thanks for your reply. I have the rails application deployed using kubernetes and have liveness and readiness probe which send get request to sign_in route.

this seems to be creating a new session id record in the table every time, is there a way i can prevent this from happening?

@aksharj
Copy link
Author

aksharj commented Oct 21, 2020

Hi @jasonfb on further investigation i also see that the ELB health checker also creates session records. Below are the entries from my nginx log

2.18.3.78 - - [21/Oct/2020:14:56:18 +0000] "GET / HTTP/1.1" 302 110 "-" "ELB-HealthChecker/2.0" "-"
92.18.63.191 - - [21/Oct/2020:14:56:18 +0000] "GET / HTTP/1.1" 302 112 "-" "ELB-HealthChecker/2.0" "-"
92.18.3.78 - - [21/Oct/2020:14:56:29 +0000] "GET / HTTP/1.1" 302 110 "-" "ELB-HealthChecker/2.0" "-"
92.18.63.191 - - [21/Oct/2020:14:56:29 +0000] "GET / HTTP/1.1" 302 112 "-" "ELB-HealthChecker/2.0" "-"
92.18.3.78 - - [21/Oct/2020:14:56:33 +0000] "GET / HTTP/1.1" 302 110 "-" "ELB-HealthChecker/2.0" "-"
92.18.63.191 - - [21/Oct/2020:14:56:33 +0000] "GET / HTTP/1.1" 302 112 "-" "ELB-HealthChecker/2.0" "-"
92.18.3.78 - - [21/Oct/2020:14:56:44 +0000] "GET / HTTP/1.1" 302 110 "-" "ELB-HealthChecker/2.0" "-"
92.18.63.191 - - [21/Oct/2020:14:56:44 +0000] "GET / HTTP/1.1" 302 112 "-" "ELB-HealthChecker/2.0" "-"

every check seems to be creating a new session table entry, any way i can exclude these type of check requests?

@jasonfb
Copy link

jasonfb commented Oct 26, 2020

why would you want a "liveness and readiness probe" check something fake?

If the "liveness and readiness probe" are supposed to hit the real sign in page endpoint, then why are you trying to change the behavior of the real sign in page endpoint?

What if I told you there were a way to bypass the session (there isn't) on just those two requests?
Now why would you want code in your app that branches only for your "liveness and readiness probe" and nothing else?

That's a code smell dude.

But either way… just don't worry about it!

What's the problem?!

This often stems from well-intentioned people creating some kind of external "liveness and readiness probe" that hits the website every few minutes.

Don't do this.

Just use NewRelic and set up alarms properly. Don't re-invent the wheel.

Generally speaking, I flush out al th records in the sessions table when they are > 180 days old anyway because the table fills up too quickly.

@jasonfb
Copy link

jasonfb commented Oct 26, 2020

if you really want a "liveness and readiness probe" just make a hit something served by Middleware (like mount a Rack app) so that it doesn't mess with the Rails session— the core problem here is that Rails was basically not designed for your use case.

@h0jeZvgoxFepBQ2C
Copy link

Maybe this is related to #154 also? Can this issue be closed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants