How to uniquely identify requests from the same tab?

[dillonforrest]

Hi there! First of all, thanks for all the awesome work on ring. Cool stuff!

I'd like my server to uniquely identify requests which come from the same tab in the same browser on the same device. Sessions aren't the right answer for me since the same session is persisting across all tabs for me.

How can ring identify between requests from different tabs? Will these ids persist even if users refresh the tab?

Disclaimer: I'm relatively new to both clojure and back-end programming :) sorry if this is a silly question!!

[dillonforrest]

Okay, I'm a giant noob and just realized I can probably leverage sessionStorage client-side. ____

Is there by any chance an idiomatic way to address my same-tab concerns with ring? If not, we should close this issue. :)

[GetContented]

No webserver/webapp can do that because the browser doesn't differentiate. If it sent some kind of tab identifier it would work, but they don't.

You can "create" this behaviour if you control all the places where requests come from. Your app would need to send an identifier along with each request. This is what Rails does for forms, for example. You can do this by making your links and forms have a param on them that you then pull out at the response end.

[GetContented]

Oh yeah, sessionStorage would work if you don't need to support pre-HTML5.

[dillonforrest]

@JulianLeviston thanks so much for the quick reply! I appreciate all that input. Lots of info I didn't know! :)

I think the only way I can accomplish my goal is to use local/sessionStorage. I can't think of any other way to isolate identity down to the tab level but persist that identity across refreshes and pageloads. It's a bummer there isn't a more stateless option, but eh, dats cool.

[GetContented]

Well you can do what I suggested, and wrap all your links and form targets with a param that's initialised on first page view... it'd be a bit hodge-podge, though. Seaside does something like this, too... every link or form target effectively has a session marker on it - it's a continuations-based system.

It all depends what you're trying to do, really. If you were building an Om app on top of it, obviously it woultn't matter because your pages don't get reloaded, so your "tab session" would just be a natural consequence of the way it works - the browser client session holds the entire state.

[dillonforrest]

I actually am doing very similarly to what you suggested! :) I'm currently planning to store a uuid in localStorage and send it with each request to my server. That uuid will be initialized on the first page view as long as the uuid doesn't already exist. Thanks for the tips!! :D