Jump to content


Photo
- - - - -

Cookies


  • Please log in to reply
No replies to this topic

#1 Dr. McKay

Dr. McKay

    Developer

  • Administrator
  • 1,810 posts

Posted 10 June 2016 - 12:33 PM

Every website out there (that doesn't use HTTP authentication) uses cookies to identify user sessions. Cookies usually contain session IDs, which are looked up on the server in order to determine who the session belongs to. Steam is no different.

 

All Steam websites (the store, community, the help site) use the same cookies to identify user sessions. There are four cookies which are required to identify a Steam session:

  • sessionid
  • steamLogin
  • steamLoginSecure*
  • steamMachineAuth<SteamID>*

* = this cookie should only be sent over HTTPS

 

Despite its name, the sessionid cookie is merely a CSRF token. Its value can be anything, as long as it matches the sessionid POST parameter in your POST requests. Steam will randomly assign you one the first time you hit one of the websites without already having one, even if you aren't logged in. They are not tied to accounts or to sessions.

 

steamLogin and steamLoginSecure are the actual session cookies. Their format is: (your 64-bit SteamID + two pipe characters, percent encoded as %7C + a 40-character uppercase hexadecimal token). The hexadecimal token will differ between the two cookies, but the SteamID will be the same. steamLoginSecure should be sent with all HTTPS requests, and only for HTTPS requests. These cookies are short-lived and once invalidated (the exact circumstances that cause them to be invalidated are unclear), you will be logged out.

 

steamMachineAuth<SteamID> is your Steam Guard identification cookie. You should replace <SteamID> with your actual 64-bit SteamID, so for example the name of my cookie would be steamMachineAuth76561198006409530. This cookie's value is simply a 40-character uppercase hexadecimal token. The cookie identifies a "machine" for Steam Guard, so that you don't have to provide an email code every time. This cookie is still present if you're using the mobile authenticator, even though you have to provide a code for every login. This cookie's issue date is also used as the "first sign in" date for purposes of determining trade restrictions. This cookie effectively lasts forever, so you should save it and reuse it between sessions. This cookie is required for trade offers to work.

 

How to Get Cookies

 

You can get Steam login cookies in one of three ways.

  1. You can log in to any Steam site in a browser, which will issue you cookies for that domain (and also do some JavaScript to set those cookies for other Steam domains). node-steamcommunity can do this for you.
  2. You can use the undocumented IMobileAuthService/GetWGToken WebAPI method with an oAuth token. node-steamcommunity can do this for you.
  3. You can use the ISteamUserAuth/AuthenticateUser WebAPI method with a nonce (loginkey) received from the CM. Sessions negotiated this way will have no steamMachineAuth cookie, and that cookie is unneeded for these sessions (trade offers will still work). Sessions negotiated this way will be invalidated as soon as the client session which received the CM nonce disconnects. node-steam-user can do this for you.

Once you have cookies, you can use them with any of a number of modules, e.g. node-steam-trade, node-steamcommunity, node-steamstore, etc.

 

Cookie Usage

 

I'll briefly explain how cookies and sessions work in my libraries. A quick overview on statefulness: HTTP is stateless. Each request is distinct from every other request, and thus there is no way to link two requests together (except by using cookies). For this reason, to keep track of which user is logged in, every site on the planet uses cookies. Typically, cookies contain an opaque session ID which the server looks up to see which account you're using. Steam is no exception. TCP is stateful. Each message sent over a TCP connection belongs to that connection and thus it's easy to link two messages together.

  • node-steam-user connects to the CM using TCP (or optionally UDP, but it acts like TCP anyway). This is a stateful connection, and there is no need to use cookies to identify it.  Therefore, node-steam-user has no need for cookies. While it is capable of producing cookies, it does not save them and doesn't use them in any way except to make them available to the end-user for use elsewhere.
  • node-steamcommunity communicates with Steam over HTTP, which is stateless. Thus, cookies are required in order to authenticate your requests to your account. node-steamcommunity can either accept cookies using the setCookies method (which can accept cookies obtained by any means, including node-steam-user), or it can produce cookies using the login method. Either method will save the cookies internally in the SteamCommunity object and those cookies will be used to authenticate every HTTP request.
  • node-steamstore is identical to node-steamcommunity, although it cannot create cookies (i.e. it can only accept them using setCookies).
  • node-steam-tradeoffer-manager is identical to node-steamstore, except it uses node-steamcommunity under the hood for its HTTP communication. Thus, if you instantiate TradeOfferManager and pass a community instance to the constructor, calling setCookies on the TradeOfferManager will also call setCookies on the SteamCommunity, and therefore you need not call setCookies on SteamCommunity (although it doesn't hurt anything, either).

In list form, where a producer can create cookies and a consumer can use cookies:


Edited by Dr. McKay, 16 July 2017 - 03:18 PM.
Added section on cookie usage

  • Royalgamer06 and ArturkA like this




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users