Jump to content
McKay Development

Dr. McKay

Administrator
 View Profile  See their activity

  • Posts

    3654

  • Joined

  • Last visited

 Content Type 

Posts posted by Dr. McKay

  2. Cookies (outdated)

    in Guides

    Posted · Edited by Dr. McKay
    Post is outdated

    This post is outdated. Please see the updated version.

    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*

    * = 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 is your Steam Guard identification cookie. You should replace 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.

    Note: Since Steam switched to HTTPS-only, steamLogin appears to no longer be necessary and is therefore no longer issued to web logins. It does seem to still be issued to Steam client-based logins.

    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 Expiration

    Cookies expire and become invalid at seemingly-random times. There seems to be no real rhyme or reason as to when it happens, but it generally does happen whenever an account is logged in somewhere else, and on some unspecific time interval.

    If you log in to Steam using node-steam-user, you will be issued cookies, but they are only linked to the CM session in that they will expire if the session disconnects. They also follow normal expiration rules, meaning that even if your Steam client session is still connected, your cookies might have expired and thus your web requests will indicate that you aren't logged in. If this happens, you'll need to use webLogOn() to get new cookies.

    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:

  17. Identifying Steam Items

    in Guides

    Posted

    Thanks for your help.

    I never consider about the issue of steam items or valve items .

    At first I  dealing with dota2 items.By getting many inventory json results and get items information by GetAssetClassInfo (eventually I made my website identifying items by market_hash_names).After that I find that if I use WebAPIs to make clear defindex+quality=market_hash_name.The volume of data can be lower as there are less description .But as you say those apps' items are complex.Using WebAPI to get items only limited in several apps(dota2 csgo tf2 steam?).

    The problem is if I want to trade .I need ids and identifing every items.Both inventory json and this IEconItems(limited apps) can provide.

    The question is I don't know how to get description only by IEconItems. like what are"attributes" means .And there are no classids,does it means IEconItems can't describe items as inventory json do?. Also ,if I want float value, IEconItems is necessary ,is there any official or unofficial documents about the result?

     

    I'm not very familiar with Dota, but as far as I know TF2 and possibly Dota are the only Valve games where IEconService gives enough useful information to build an item's display information. For everything else, you need to use inventory JSON.

     

    Attributes are only a concept in Valve-land; the Steam econ server has no concept of "attributes". Consequently, attribute data doesn't translate to the inventory JSON. Attributes are just that: attributes attached to an item. For example in TF2 an attribute might change how much damage the weapon does. In CS:GO, wear is an attribute.

     

    IEconService has no classids because again, it has no concept of classids. They're entirely assigned by and used by the Steam econ server, and consequently they're only available in the econ endpoints (like inventory JSON and GetAssetClassInfo).

  18. Identifying Steam Items

    in Guides

    Posted

    On 5/31/2016 at 12:58 AM, vshezhuoji said:

    -snip-

     

    I purposefully didn't mention the WebAPIs because they aren't really "Steam items". They're "Valve items", and third-party games don't need to follow any of the same standards. However, for Valve games, the "id" in the WebAPI is the item's asset ID, and "original_id" is the item's asset ID when it was originally created. If it's identical to the item's "id", that means that the item was never traded or modified. Quality (generally) determines the color of the item's name, and (sometimes) a prefix to the item's name (for example, StatTrak, ★, etc). Quality has nothing to do with wear.

     

    For CS:GO, you can't really get much useful information out of the WebAPI except an item's raw wear value (frequently, incorrectly, and ignorantly referred to as its "float value") and perhaps original ID.

  21. Identifying Steam Items

    in Guides

    Posted

    So there isn't any easy way to link an item the bot received to the original owner?

     

    In my project we may need to give items back to the user. If the items can change their names and their 5 IDs after a trade or something, we'll have to figure out a guaranteed way to make sure that we will always know who were the owners of the items, and this sounds too much difficult...

     

    Can anyone here help me with this?

     

    The trade receipt page contains the new item data. If you're using node-steam-tradeoffer-manager, you only need to use offer.getReceivedItems.

×
×
  • Create New...