What kind of cookies does meteor set?

A lawyer is writing a terms & conditions for one of my apps. They asked what kind of cookies does we use and I’m not sure what Meteor uses:

  • session cookie
  • persistent cookie
  • cookie for a password protected session
  • security cookie (?)

I’m not even sure what the last 2 might be. Has anyone has a T&C which mentions cookies?

Meteor doesn’t use cookies by default. It uses local storage.

1 Like

Some popular packages set cookies, like fast-render. Also, if you use Google Analytics etc., those set cookies.

Open up dev tools on your site, find the “Application” tab and inspect which cookies are set on your domain.

1 Like

Thanks. If anyone is interested, Galaxy uses a session cookie (galaxy-sticky).

1 Like

Can you clarify? Is galaxy-sticky a package name or the cookie name? Why does galaxy use a cookie when accounts packages use local storage? My understanding was that Meteor does not use cookies in order to meet Galaxy PaaS requirements/restrictions.

Suppose all of these are key/value stores. For each:

Session cookie stores a value for who the user is for the current session (phew user is authenticated, let’s store that info)
Persistent cookie is how we recognize the user at a later time (phew the user is authenticated, thankfully we stored that info)
Cookie for a password protected session says that we found who a user is for authentication and we told them to provide a password for future reference. (phew the user is authenticated, thankfully we stored that info)
Security cookie I presume says we’ve added more cryptography to a key/value for example by providing a symmetric or asymetric hash as an additional cookie.

As always I destroy my reputation by posting here. Dissent is expected.

[Edit: I deleted this post before subsequent comments and then restored it.]

Usually loadbalancers use cookies to make your session always go to the same server (sticky sessions) is not a meteor feature, is used by your server config, in this case galaxy.

Cookies are based on domain, the load balancers are under the DNS server/IP address. What makes a “session” “sticky” other than being a properly configured session?

Im not sure, but I think the domain has to point to the load balancer and that one points later to each app server. So the load balancer gets the cookie and forwards the requests to the server from the cookie.