We all know that SteamGifts (SG) does not identify many owned games. This appears to cause a lot of reroll and deletion requests, which also appear to be slow to occur. For this reason, I use ESGST to identify owned games so that I can 'ignore/hide' them on SG. I have not seen an instance where ESGST made a mistake, that is, mark a game as owned when it was in fact it was not owned by me.

I have also seen a number of suggestions to fix this SG 'bug' such as:

  • implement a warning for all games known to be affected (Steam is learning etc)
  • Software being sold that loads your owned game list and marks them 'ignored/hidden' on SG

It seems to me that if ESGST can correctly identify games, as well as other paid software which I have not tried and cannot verify, why can't SG? Rather than SG potentially spend resources to create a workaround for a bug, why not fix it?

Can anyone identify a reason why SG would not or should not?

1 week ago

Comment has been collapsed.

What is your preferred solution to the SG bug that does not correctly identify owned games?

View Results
SG is fine the way it is. I don't mind making reroll and deletion requests and don't see any better use of the mods time
SG should fix the bug so that games are correctly identified as owned the way that ESGST and other software are able to
Rather than fix the bug, SG should implement a warning to the effect of 'you may or may not already own this game'
(obligatory) potato

ESGST uses this link https://store.steampowered.com/dynamicstore/userdata/
And this link shows the data for your current logged in account.
ESGST can see it because you are logged in in your browser (and it will show you an error if you suddenly are not logged in).
So, on SG servers there is no your account logged in, so SG can't check it.

SG uses steam API, and this API does not return all that 'learning' things.

1 week ago
Permalink

Comment has been collapsed.

It has been a long time since I have done any programming. I am no longer a technical guy, so I am open to explanation as to why this is not possible. but I am sure that we are logged into Steamgifts accounts to be able to enter giveaways and post posts. Maybe I'm missing your point?

1 week ago
Permalink

Comment has been collapsed.

You must be logged in with your "steam account" for esgst to work. For example - I'm logged in on steamgifts for about 2 months without logging out. In the meantime steam logs me out automatically everyday :)

But i don't think it's a big problem. SG could save additional data when you are logged in with steam - you will just have to remember to log in occasionally.

1 week ago
Permalink

Comment has been collapsed.

Thank you. I appreciate the response, your time and effort

6 days ago
Permalink

Comment has been collapsed.

Well, there are two ways of retrieving data from Steam.

SG uses Steam API. It means that SG make a request to a special address, for instance https://api.steampowered.com/IPlayerService/GetOwnedGames/v1/?key=XXX&steamid=76561198005585830. This link has your ID in it as an example, so if SG makes this request - it gets your data, if I make this request - I too get your data, and so on. If I want to get my data, I need to change your SteamID with mine. The information we get with this link - it depends on how the link is formed (whose SteamID is in it, it's a parameter).

But there is another way. Imagine we have a link, like this: https://store.steampowered.com/account/licenses/
When you are visiting it from your browser, you see your information. When I'm visiting it, I see mine. But the link is the same, Steam has a cookie( or something like that) to identify the user who is trying to access the information, and that's why it shows you yours, and it shows me mine.
So what will happen if SG makes a request to this link, whose information will it get? It won't get anything (or maybe it will get cg's info, if there is some authorization data on the SG server, but I'm not sure on this part), because there is no SteamID in the link, there is no way to identify, which user's information we want to get with this link. (And it's done this way because this information is private, and should not be available via API.)

The same goes with this link https://store.steampowered.com/dynamicstore/userdata/
There is no way for SG to make requests to this link by adding a SteamID to it, cause this link is working only for the account, logged in currently in the browser. ESGST can access it because it's an extension, so it has some access to your browser data. SG can't access it, cause it doesn't have access to your browser data, besides some tiny things like your IP, cookies (for SG site only, it doesn't have access to your Steam cookies) and so on.

So here goes the difference: the API way is designed to be used by anyone else to retrieve any available information (unless you make your account private). The second way is designed to be used by individuals to retrieve their own information only.

I think I'm not very good at explaining things, and English is not my native, but I hope I managed to make it more clear for you.

1 week ago
Permalink

Comment has been collapsed.

Thank you. I appreciate the response, your time and effort

6 days ago
Permalink

Comment has been collapsed.

if ESGST can correctly identify games, [..] why can't SG

A comment I wrote up for an earlier instance of this topic:

The Steam API has two methods of access, the developer access (that is used by any 3rd party [eg, website] to access multiple user accounts) and the user access (that is used by a specific user to access their own account information, and which is utilized by browser scripts and idling software and the like).
The developer access doesn't give out information on DLC ownership, so you'll always be able to enter any giveaway on SG for a DLC, or for a package which includes at least one DLC [as it is impossible for SG to recognize if you own the content in question]. The exception is when you've previously won that DLC through SG, as SG can check against the site's history of your wins in that circumstance.

In other words, SG can't tell what DLCs you own because they're using their own login, rather than yours, and they thus don't have the permissions necessary to access some of your information. Unless Steam changes it so DLCs can be recognized by non-personal logins, there's nothing SG can do about the matter.

As far as your suggestion for SG to note which games are profile limited/etc, I'm under the impression that Steam doesn't send any of that information out through the API. So there'd be no way for any special circumstances games to be recognized by SG outside of staff manually flagging them, and that'd be too demanding and unreliable to be feasible.

1 week ago*
Permalink

Comment has been collapsed.

Does this suggest that if the login on Steamgifts was different, then the information would be available?

1 week ago
Permalink

Comment has been collapsed.

When Steamgifts pulls data for the site's general use, they're going to be using the developer login. I believe that Steamgifts currently doesn't make any use of individual user steam community logins past the initial registration. After all, I've been using the site without being logged to community [within the same browser] for years now. :P

I suppose in theory Steamgifts could just utilize community login to integrate such personal elements, especially since they're more a convenience factor than anything integral to the functioning of the site's core foundations. Unfortunately, the extent of my knowledge of the underlying mechanics involved ends around that point, so that possibility would be something you'd have to check against with those who've done more with Steamworks development.

The best people to ask would likely be the Steamgifts associated backlog/library management groups [such as Backlog Assassins]- after all, given their focus on organizing a user's library, they'll have likely considered such matters in depth. SteamDB, ITAD, and the other major steam community associated sites may be options as well, as I believe most of them have their own community discussion areas that could be made use of. There seem to be a handful of users with Steamworks development experience just floating around on SG, so it's also an option to just create a general inquiry thread.

Anyway, tl;dr, I can't tell you if Steamgifts could potentially access that information, I can only tell you that it has previously been clarified that Steamgifts' current structure cannot, and the basis given for such was what I described in my earlier post.

/

As far as profile features limited and so forth, I don't think there'd be any way to get proper info on those, since the issue there is related to what is coming off the store pages, not anything related to user data. Same basis for why there doesn't seem to be a way to fix [Daedelic/etc] point/contribution value inflations during sales [as that data actually screws up on Steam's end, as can be noticed via the same incorrect values being given through steam store searches during the sales].

1 week ago*
Permalink

Comment has been collapsed.

Thank you. I appreciate the response, your time and effort

6 days ago
Permalink

Comment has been collapsed.

Although SteamGifts could technically access that information just by making a client-side window.fetch request with credentials: 'include' to https://store.steampowered.com/dynamicstore/userdata/, which would make a request using your current cookies and, therefore, retrieve the list if you're logged in, this isn't possible because of CORS. Any requests made from SteamGifts to Steam would be blocked because they are not the same domain. ESGST is able to bypass this restriction because extensions don't belong to any domain (and same goes for userscripts on Tampermonkey, etc.).

6 days ago
Permalink

Comment has been collapsed.

Thank you. I appreciate the response, your time and effort

6 days ago
Permalink

Comment has been collapsed.

Despite everything said above, there is absolutely no reason for SG to avoid optional userdata upload, similar to barter.vg sync. While API sync should remain primary and mandatory (because nobody can tamper with data), userdata sync should be optional, allowing the user to correctly mark remaining packages as owned, therefore hiding them from results and making all of our lifes much easier. Writing userscript and backend for that is a few hours tops.

Problem is, since this data comes from the user, you can no longer trust it, therefore it has to be optional by definition.

6 days ago
Permalink

Comment has been collapsed.

Thank you. I appreciate the response, your time and effort

6 days ago
Permalink

Comment has been collapsed.

There really can't be any harm in users marking all the games as owned here preventing themselves from entering any giveaways for them can there? As long as you only take the additional information provided and don't allow users to unmark games the API already said they own.

6 days ago
Permalink

Comment has been collapsed.

Which is why I put emhasis on optional. Yes, at worst user can just limit himself further from joining giveaways, and I see absolutely no harm here. The key thing to understand here is that API way should not change in any way to prevent abuse. Userdata upload would be optional feature for users that want to make use of it, in order to forbid themselves from entering DLCs/learning/packages they already own.

6 days ago
Permalink

Comment has been collapsed.

It is not like we don't do that already with the filter list* so all that would do it is make it easier to add all the ones you own but don't show up saving a lot of effort.

*I have over five thousand on it myself.

5 days ago
Permalink

Comment has been collapsed.

They are two very different things. The API endpoint SG (and many other websites) use is a public, documented, and monitored (by the way of API Keys used to authenticate and authorize requests to it) API. That API is provided for integration with other platforms.

The way ESGST and other scripts pull data is by using a private, undocumented, subject to change at any time and without warning, API endpoint. That endpoint is used inside the Steam store website. As such, it's not public nor documented by Valve. You must dig into the code to find it. It also has different restrictions. One being you must be signed in with an account in Steam, so you are given the proper cookies to be able to make that request. Without those cookies, Steam wouldn't know which user you are, and therefore would return nothing.

Either way, SG wouldn't be able to make that request from the client-side like scripts and extensions do. Scripts and extensions can bypass something called CORS, Cross-Origin Resource Sharing. CORS is important, and is enabled by default (and can't be disabled in many) browsers. It prevents websites from making requests to other websites. This is done to prevent some malicious code injected in say X website, that otherwise would be secure, to send all your cookies and login details and such to any other website Y.

A client-side request, like scripts and extensions do, would keep the cookies needed for the authentication in with the request, so from a script or extension you don't need to know the login details (email and password) of a user. But as I pointed out already, it's not possible for SG to make a client-side request since CORS. And you might thing: "What about a request from the server side"? From the server side, the server would have no idea of what your cookies for authorization are, and no way of getting them. That is, unless you provided your email and password to the website, and the website on the server-side used those to login, and then got the cookies and made the request to the private endpoint that has the DLC info. This is a bad idea for many reasons. But basically, would you give your email username and password to any website that requested it? If you answered yes, I don't even know what to tell you.

6 days ago
Permalink

Comment has been collapsed.

Sign in through Steam to add a comment.